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1.0  SCOPE 

This  document  establishes  the  functional  require¬ 
ments  for  the  PAVE  PILLAR  Systems  Architecture.  This 
architecture  is  specifically  targeted  for  advanced  tactical 
fighters,  and  in  general  for  all  military  aircraft 
applications.  The  PAVE  PILLAR  Architecture  addresses  those 
functions  which  could  be  implemented  with  common  hardware  and 
computer  programs  to  allow  adaptation  to  either  air-to-air  or 
air-to-ground  missions.  This  document  defines  the  ma.ior 
elements  of  the  PAVE  PILLAR  Architecture,  the  mechanizations 
for  interconnecting  those  elements,  a  set  of  common  modules 
from  which  those  elements  could  be  constructed,  and  the 
operation  of  the  network  constructed  of  these  elements. 

This  document  describes  a  fully  Integrated 
architecture  concept  which  includes  common  data  and  signal 
processors.  Section  6.4  addresses  the  issue  of  non-homogeneous 
processing  resources. 

Appended  to  this  document  is  a  set  of  specifications 
which  represent  current  physical  and  functional  interface 
specifications  for  the  PAVE  PILLAR  architecture  as  implemented 
by  Advanced  Development  Model  f  A  HM )  technology  programs.  As 
such,  these  specifications  may  by  revised  and  expanded  where 
necessary  when  applied  to  Full  Scale  Engineering  Development 
( F S F D )  programs. 
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2.0  APPLICABLE  DOCUMENTS 

2 . 1  Military  Standards 

MIL-STD-1553B,  Aircraft  Internal  Time  Division  Com- 
mand/Res ponse  Multiplex  Data  Bus 

MI L-STD-] 750A  16  Bit  Computer  Instruction  Set 

Arch i tecture 

MIL-STD-1760  Aircraft  Store  Electrical  Interconnec¬ 
tions  System 

MI L-STD-1815A  Ada  Programming  Language 

MIL-STD-483A  Configuration  Management  Practices  for 
Systems.  Equipment,  Munitions,  and  Computer  Programs 

MIL-STP-490A  Specification  Practices 

DOD-STD-2167  Defense  System  Software  Development 

2 . 2  Other  Publications 

NASCIM  5100A  (Cl  Comprising  Emanations,  Laboratory 
Test  Requirements,  Electromagnetic 

NACSEM  5112  (S-NF)  Non-Stop  Evaluation  Techniques 

NACSEM  5201  (Cl  Tempest  Guideline  for  Equ  i  pmeri  t/Sys  - 
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3,0  REQUIREMENTS 

3 . 1  Avionics  Systems  Definiti on 

An  avionics  system  is  a  suite  of  equipment 
integrated  into  the  aircraft  to  enable  the  pilot  to  accomplish 
the  assigned  missions  of  a  tactical  fighter  aircraft  weapon 
system.  The  avionics  system  is  divided  into  four  functional 
areas:  1)  Sensor/Subsystems,  2)  Digital  Signal  Processing, 

3)  Mission  Processing,  and  4)  Vehicle  Management  Processing. 

Figure  3.1-1  shows  the  components  and  the  communica 
tion  network  for  the  Vehicle  Management  Processing  Area,  Digi¬ 
tal  Signal  Processing  Area,  and  the  Mission  Processing  Area. 

3 . 1 . 1  PAVE  PILLAR  Core  Avionics 

The  PAVE  PILLAR  core  avionics  exploits  the  com¬ 
monality  in  air-to-air  and  air-to-ground  missions.  The  PAVE 
PILLAR  core  avionics  consists  of  the  following  functional 
areas:  1)  Digital  Signal  Processing,  ?1  Mission  Processing, 

3)  Vehicle  Management  Processing,  and  4)  Avionics  Systems 
Control.  The  Digital  Signal  Processing,  Mission  Processing, 
and  Vehicle  Management  Processing  areas  define  the  enclosing 
boundaries  for  resource  sharing,  sparing,  and  substitutions. 
Unique  characteristics  of  each  of  these  areas  preclude  the 
utilization  of  the  resources  across  areas  for  the  purpose  of 
functional  recovery  or  reconfiguration, 

3 . 1 . 1 . 1  Digital  S i goal  Process i H2_Area 

The  Digital  Signal  Processing  Area  provides  the 
resources  to  perform  the  digital  signal  processing  for  radar, 
electronic  warfare,  image  and  CNI  processing.  Resources  will 
be  provided  to  route  sensor  data  from  the  sensor/subsystem  to 
the  appropriate  signal  processing  element.  Resources  will  be 


Flgur*  3.1-1  AVIONICS  SYSTEM  FUNCTIONAL  ORGANIZATION 
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provided  to  exchange  data  between  signal  processing  elements. 
The  ma.ior  components  of  the  Signal  Processing  Area  are  a  set  of 
common  signal  processors,  a  sensor  data  distribution  network,  a 
sensor  control  network,  a  data  exchange  network,  and  a  video 
data  distribution  system. 

3. 1.1. 2  Mission  Processing  Area 

The  Mission  Processing  Area  provides  the  resources 
to  perform  mission  and  system  management  such  as  fire  control, 
target  acquisition,  navigation  management.,  defense  management, 
stores  management,  TF/TA/OA  functions,  and  crew  station  manage¬ 
ment.  The  Mission  Processing  Area  controls  the  reconfiguration 
of  the  Digital  Signal  Processing  Area  and  determines  the 
routing  of  the  data  from  the  sensor/subsystem  to  the  signal 
processing  elements.  The  Mission  Processing  Area  collects  the 
health  and  status  of  all  avionics  components  for  maintenance 
history  and  maintains  a  record  of  mission  functional 
capability.  The  components  of  the  Mission  Processing  Area  are 
mission  data  processors,  mission  avionics  multiplex  bus,  block 
transfer  multiplex  bus,  system  mass  memory,  stores  management 
system,  and  a  collection  of  interfaces  to  the  mission  avionics 
multiplex  bus. 

3 . 1 . 1 . 3  Vehicle  Managemen t  Sy stemsArea 

The  Vehicle  Management  Systems  Area  provides  the 
resources  to  support  the  fundamental  flight  and  airframe  re¬ 
lated  control  functions  listed  in  Table  3 . 1.1. 3-1 .  The  com¬ 
ponents  of  the  Vehicle  Management  System  Area  are  vehicle 
management  system  data  processors,  con trol /d i spl ay  interfaces, 
flight  sensor/actuation  interfaces,  electrical  power  control 
interfaces,  engine  control  interfaces,  and  utility  systems 
i  nterfaces . 
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TARLF  3. 1.1. 3-1 

VEHICLE  MANAGEMENT  SYSTEM  FUNCTIONS 

FI i ght  Control 
Inlet  Control 

Prcpu 1 s i on  Control  v 

Vector  Thrust  Control 
Air  Data  Measurement 
Aircraft  Inertial  Measurement 
Electrical  Power  Control 
Utility  Systems 

Fuel  Measurement  and  Transfer 
Fuel  Inerting  System 
Environmental  Measurement  and  Control 
Life  Support  Control 

r  mni.i  Cr  a  n/i 
V/  i  t  n  i .  j  lu  pc 

Hydraulic  System 
Landing  Gear 

Auxiliary  Functions  (Refueling,  Landing  Lights,  etc,) 
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3 . 1 . 1 . 4  Avionics  Systems  Control 

Control  of  the  PAVE  PILLAR  avionics  is  vested  in  a 
distributed  control  architecture  providing  for  a  maximum 
efficiency  in  resource  utilization,  mission  effectiveness,  and 
commonality  of  control  software  across  major  processing  units. 
Major  control  functions  must  include: 

1)  Initialization  and  system  start-up/restart 

2)  Assignment  of  application  software  task  to  pro¬ 
cessing  resources  (software  configuration  and  reconfiguration 
computing  resources  management! 

31  Sequencing  and  synchronization  of  related  soft¬ 
ware  tasks 

4)  Management  of  sensor  and  other  device  resources 
with  respect  to  mission  objectives,  mode/task  management  and 
software  parameters 

5)  Interpretation  of  response  to,  and  integration 
of,  human  control  into  the  system  functionality 

61  Collection,  maintenance,  and  reporting  of  system 
hardware  and  software  status,  and  operational  functionality 

7)  Response  to  hardware  and  software  failure  detec¬ 
tion  to  preserve  mission  effectiveness 

8 1  Flight  control  change  management  and  response 

9)  Reintegration  of  recovered  hardware  and  software 

functions 
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10)  Assurance  of  a  distributed  data  base 
consistency  and  integrity,  and  management  of  access  to  that 
shared  data 

11)  Preservation/collection  of  data  required  for 
continuity  of  system  functionality  across  failure  recovery 
points 


12)  Management  of  communications  access  to  assure 
optimal  use  of  communication  resources  and  correct  addressing 
of  data  messages 

13)  Assurance  of  the  security  of  classified  data. 


The  avionics  systems  control  functions  of  the 
operating  system  snail  be  partitioned  into  three  elements: 

1)  The  system  executive  which  will  provide  the  monitoring  of 
system  state  and  the  reconfiguration  based  upon  mission 
requirements  and  detected  system  failures;  2)  the  distributed 
executive  which  will  provide  for  decentralized  system  control 
in  each  processor;  3)  the  kernel  executive  which  will  provide 
those  operating  system  functions  which  are  common  to  all 
processors.  Figure  3. 1.1. 4-1  depicts  the  interrelationship  of 
the  three  elements. 

3.1.2  M  i  s  si  oris  The  PAVE  PILLAR  core  avionics  will 
support  both  air-to-air  and  air-to-ground  tactical  missions. 

3.1.3  0££Iill2J2.4i,_C  o  n  c  e£t 

The  PAVE  PILLAR  architectural  concept  was  developed 
to  support  aircraft  operations  from  deployed  locations  with  a 
minimum  of  support.  This  architecture  supports  the  resource 
sharing  of  core  data  and  signal  processing  resources  and  is 
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constructed  of  a  set  of  common  modules  that  specifically 
support  a  two -level  maintenance  concept.  This  architecture 
supports  high  degrees  of  systems  availability  and  reliability. 
This  is  accomplished  through  the  application  of  spare  signal 
and  data  processing  resources  at  the  system  level  so  that 
backup  services  are  provided  when  the  primary  sources  fail.  In 
addition,  the  architecture  supports  graceful  degradation  in 
that  when  spare  resources  are  exhausted  remaining  resources  can 
be  assigned  to  the  highest  priority  functions  on  a  mission 
basis. 

3.1.4  e  m_  0i£5ram_s 

The  PAVF  PILLAR  core  avionics  systems  and  their 
common  components  are  shown  in  Figure  3. 1.4-1.  A  detailed 
description  of  each  of  the  common  components  is  presented  in 
Paragraph  3.7. 

3.1.5  Interface  Definition 

3 . 1 . 5 . 1  Functional  Interfaces 

The  PAVF  PILLAR  core  avionics  interfaces  with  the 
sensor/subsystems,  the  crew  station  avionics,  and  the  weapons. 
Interface  control  documents  will  be  developed  for  each  sensor/ 
subsystem  that  interfaces  with  the  PAVE  PILLAR  core  avionics. 
The  preferred  concept  is  that  all  System  Element  Level 
Interfaces  be  implemented  using  Fiber  Optic  Technology  and  make 
maximum  use  of  common  interface  definitions. 

3.1.5.?  Mission  Avionics  Multiplex  Bus 

The  Mission  Avionics  Multiplex  Bus  connects  all  the 
mission  data  processors,  vehicle  management  system  data  pro¬ 
cessors,  signal  processors,  sensor  data  distribution  network. 
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data  exchange  network,  video  data  distribution  network  and 
mission  Interface  terminals. 

3 . 1 . 5 , 3  Block  Transfer  Multiplex  Bus 

The  Block  Transfer  Multiplex  Bus  is  connected  to  all 
the  mission  data  processors,  the  system  mass  memory,  and  data 
transport  units.  The  Block  Transfer  Multiplex  Bus  shall  be 
used  to  load  volatile  processor  memories  and  transfer  large 
blocks  of  data. 


3. 1.5. 4  Video  Data  Distribution  System 


The  Video  Data  Distribution  System  integrates  the 
video  distribution  system  on  two  levels.  The  two  levels  are 
the  Internal  Video  Data  Distribution  Network  fVDDNl  arid  the 


external  (or  stores  1  vide* 


v  n  n  m 


provide  the  interface  between  the  cockpit  displays,  the  stores 
management,  and  the  signal  processors.  The  VDDN  is  controlled 
through  the  Mission  Avionics  Multiplex  Bus.  The  external  video 
distribution  shall  route  the  video  lines,  defined  in  the 
MIL-STD-1760  Stores  Interface  Requirements,  to  the  stores 
management  system  where  any  of  the  video  signals  may  be 
selected  by  the  stores  interface  to  be  connect  d  to  the 
internal  video  distribution  system. 


3 . 1 . 5 . 5  Sensor  Data  Pis tr_i  bu t ion  Network 

The  Sensor  Data  Distribution  Network  (SDDN)  shall 
allow  any  one  sensor's  data  to  be  distributed  to  any  one  signal 
processor.  The  SDDN  Is  controlled  through  the  Mission  Avionics 
Multiplex  Bus. 
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3 . 1 . 5 . 6  Sensor  Control  Network 

The  Sensor  Control  Network  shall  provide  the  com¬ 
munication  paths  from  any  signal  processor  back  to  the  sensor 
subsystem  it  is  controlling  and  receiving  data  from.  The 
Sensor  Control  Network  is  part  of  the  SDDN  routing  network  and 
is  also  controlled  through  the  Mission  Avionics  Multiplex  Bus. 

3 . 1 . 5 . 7  Data  Exchange  Network 

The  Data  Exchange  Network  shall  provide  the  com¬ 
munication  paths  between  the  system  mass  memory,  the  signal 
processing  areas,  and  COMSEC/TRANSEC  controllers.  The  Data 
Exchange  Network  is  controlled  through  the  Mission  Avionics 
Multiplex  Bus. 

3 . 1 . 5 . 8  Vehicle  Management  Systems  Multiplex  Bus 

The  Vehicle  Management  Systems  Multiplex  Bus  shall 
interface  the  Vehicle  Management  Systems  data  processors  with 
•Hat  panel  display/cockpit  switches  and  integrates  the  flight 
propulsion  and  electrical  subsystems. 

3 . 1 . 5 . 9  Mechanical  Interfaces 

The  mechanical  interfaces  with  PAVE  PILLAR  core 
avionics  will  be  determined  by  the  contractor  and  documented  in 
the  mechanical  interface  document. 
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3.1.5.10  Environmental  Interfaces 

The  PAVE  PILLAR  core  avionics  will  provide  the 
specified  performance  when  interfaced  with  an  aircraft  en¬ 
vironmental  control  system.  The  environmental  control  for  the 
avionics  will  be  determined  by  the  contractor  and  documented  in 
the  interface  control  documents. 
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3.1.6  n.  .t  List  (None) 

3 . 2  Avionics  System  Characteristics 

3.2.1  Performance  Characteristics 

3 . 2 . 1 . 1  Fault  Tolerance 

State-of-the-art  techniques  in  both  hardware  and 
software  designs  shall  be  used  to  establish  a  high  level  of 
system  tolerance  to  both  hardware  and  software  failures.  The 
essential  capabilities  to  be  provided  include  the: 

1)  Ability  to  detect,  correct,  or  compensate  for 
soft  errors  induced  by  transient  hardware  or  environmental 
anomalies.  For  example,  memory  bit  errors,  data  transmission 
errors,  etc. 

2)  Ability  to  detect,  locate  and  isolate  non- 
automatical ly  correctable  hardware  and  software  failures  so 
that  graceful  recovery  reconfiguration  may  take  place  without 
loss  of  data  or  function.  Where  the  nature  of  the  failure  ne¬ 
cessitates  recovery  to  a  degraded  mode,  any  data  loss  or  func¬ 
tional  loss  must  be  identifiable  and  under  the  control  of  the 
system.  In  the  maintenance  mode,  detection  and  localization  of 
faulty  hardware  to  a  line  replaceable  module  must  be  provided. 

3)  Ability  to  recover  from  soft  and  hard  failures 
with  minimum  disruption  to,  or  intervention  of,  the  user  and 
maximum  preservation  of  system  function  optimized  toward  the 
objectives  of  the  current  mission. 

4)  Ability  to  contain  faults  to  prevent  the  spread 
of  system  or  data  contamination. 


-  14  - 


7* 


SPA  90099001  A 
16  January  1987 


3. 2. 1.1.1  Hardware  Fault  Tolerance 


The  hardware  techniques  that  shall  be  applied  to 
providing  the  required  detection  capability  and  hardware 
remedies  shall  include  the  use  of  redundant  busing,  spare  and 
redundant  common  modules,  hot  standby  spare  and  dual  redundant 
processors,  sel f -checki ng  hardware  circuitry  and  built-in  test. 


•i 


V 


3 . 2 . 1 . 1 . 2  Software  Fault  Tolerance 

Software  fault  tolerance  shall  be  provided  for  each 
processor.  Software  fault  tolerance  shall  be  provided  through 
the  use  of  dynamic  error  handling  techniques.  These  techniques 
involve  the  use  of  operational  software  code  to  detect, 
confine,  and  correct  software  data  and  timing  errors  during 
systems  operation,  in  order  to  limit  the  duration  of  a  software 
failure  or  to  prevent  a  software  error  from  causing  a  software 
failure,  if  possible.  A  software  failure  is  an  event  caused  by 
software  error  which  results  in  service  interruption.  A 
software  data  error  is  an  item  of  information  generated  b.v 
software  fault  which  leads  to  a  service  interruption  if  left 
uncorrected.  A  software  timing  error  is  a  situation  caused  by 
a  software  fault  which  prevents  an  item  of  information  from 
being  provided  within  a  specified  time  or  sequence.  Dynamic 
error  handling  techniques  shall  be  specified  as  appropriate  for 
critical  or  complex  logic,  critically  timed  services,  all 
interfaces  including  software/hardware  and  hardware/hardware 
input  data,  and  critical  data  values. 

3 . 2 . 1 . 2  Configuration/Reconfigurati o n_ C  ha  ra  cter i sti cs 
3 . 2 . 1 . 2 . 1  Start-up 

In  high  level  terms,  the  bulk  of  the  system  level 
control  will  be  centered  in  the  mission  processors  designated 
as  the  system  executive  and  its  redundant  backup.  Since  these 
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processors,  as  hardware,  shall  be  identical  to  all  other  pro¬ 
cessors,  the  determination  of  the  specific  processors  to  act  as 
system  supervisors  may  be  flexibly  accomplished.  Executive 
software  shall  detect  the  absence  of  supervisors  in  the  system 
upon  start-up  and  respond  by  adopting  the  supervisor's  role. 
The  processors  to  adopt  this  role  will  be  the  ones  that  first 
acquire  access  to  the  Block  Transfer  Multiplex  Bus  and,  there¬ 
by,  to  the  System  Mass  Memory  in  the  absence  of  supervisors. 
These  processors  shall  proceed  with  self  tests  and  load  the 
mission  management  and  system  level  executive  software.  This 
software  shall  be  unique  to  the  processors  that  fulfill  the 
supervisor's  role.  Subsequently,  as  they  oain  access  to  System 
Mass  Memory,  all  other  Mission  Data  Processors  shall  execute 
self  tests  and  shall  be  loaded  to  establish  an  initial  mission 
software  configuration  in  accordance  with  the  functionality 
dictated  by  the  mission  plan  and  data  base  resident  in  System 
Mass  Memory.  The  system  supervisor  shall  verify  that  the 
required  status  is  reached  by  the  full  complement  o*  mission 
processors  and  report  positively  t.o  the  crew  upon  successful 
completion  of  this  stage.  In  the  event  that  the  required 
status  is  not  reached  within  a  reasonably  defined  time  period, 
a  fault  condition  shall  be  reported.  If  automatic  recovery 
from  the  deficient  system  condition  is  appropriate,  the 
supervisor  shall  initiate  recovery  procedures.  Once  the  Mis¬ 
sion  Data  Processing  configuration  is  established,  the 
supervisor  shall  begin  gathering  status  data  on  all  system  ele¬ 
ments  accessible  on  the  Mission  Avionics  Multiplex  Bus,  As 
establishing  communications  reveals  that  these  elements  have 
become  operational  (as  a  consequence  of  their  start-up  pro¬ 
cedure),  updated  status  displays  will  be  generated  and  trans¬ 
mitted  to  the  cockpit.  The  operational  availability  and  status 
of  each  PAVE  PILLAR  element  or  interface  subsystem  shall  lie 
compared  against  the  mission  resource  requirement.  If  full 
mission  capability  is  reached,  this  fact  shall  be  reported. 
Until  that  occurs,  a  report  that  mission  resources  are  lacking 
will  be  made  available  to  the  crew. 
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3 ,  ?  ,  1 .  ?. .  1 . 1  Vehicle  Management  System  Area  Start-up 

In  a  completely  autonomous  cycle,  the  Vehicle 
Management  Systems  Area,  under  the  control  of  the  mission 
independent  Read  Only  Memory  (ROMl  software,  shall  establish 
itself  carrying  out  self  test  upon  start-up  and  verifying  all 
VMS  bus  devices  and  interfaces.  Status  reporting  by  the  VMS 
processor  shall  be  made  independently  to  the  cockpit  and  to  the 
Mission  Processing  Area.  Upon  VMS  processor  request,  any 
system  data  required  for  integrated  systems  operation  and 
communication  shall  be  provided  to  the  VMS  processor  by  the 
responsible  Mission  Data  Processor ( s  1 .  The  VMS  shall  be 
capable,  however,  of  entirely  autonomous  operation  and  shall 
exercise  complete  control  over  VMS  to  Mission  Processing  Area 
communications  as  well  as  over  its  own  interfaces  to  the  cock¬ 
pit  subsystem.  No  software  load  shall  be  required  since  the 
necessary  software  exists  in  Read  Only  Memory. 


3 . 2 . 1 .  2 . 1 ,  ?.  Digital  Signal  Processor  Area  Start-up 


The  control  processors  within  the  signal  processors 
shall  be  responsible  for  control  of  signal  processor  testing 
and  internal  module  operational  status  gathering  which  it  shall 
report  to  the  system  supervisor.  When  the  supervisor  has 
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shall  make,  based  upon  mission  requirements,  an  assignment  of 
signal  processor  to  sensor/subsvstem  signal  sources.  The 
supervisor  shall  send  appropriate  control  data  to  the  sensor 
signal  switching  network  controller  to  set,  up  the  determined 
configuration  and  the  signal  processor  shall  be  instructed  as 
to  their  required  software  loads  which  they  shall  proceed  to 
acquite  from  System  Mass  Memory.  Once  loaded,  each  signal 
processor  shall  establish  and  test  communications  with  its  as¬ 
signed  sensor  subsystem  on  both  control  and  data  communications 
networks.  The  status  of  these  operations  shall  be  reported  to 
the  system  supervisor  by  each  signal  processor  as  data  for  the 
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supervisor's  evaluation  of  mission  readiness  and/or  recovery 
initiation.  Appropriate  protocol  and  time-out  thresholds  to 
allow  detection  by  the  supervisor  of  failures  in  the  signal 
processing  area  during  these  activities  shall  he  established. 

3.2.1.?.? 

Any  operational  state  that  is  stable  (that  is,  fault 
processing,  recovery  processing,  or  mode  change-over  processing 
are  not  active)  shall  be  termed  "normal  operations."  Thus, 
normal  operations  may  include  degraded  but  stabilized  modes  of 
operation.  During  normal  operations,  the  role  of  the  system 
supervisor  diminishes  to  monitoring  a  software/hardware  con¬ 
figuration  and  status  of  Mission  Data  Processor  tasks  and  Mis¬ 
sion  Avionics  Multiplex  Bus  devices  with  respect  to  mission 
requirements  (for  example,  to  detect  an  event  or  time  requiring 
flight  mode  changes)  and  to  performing  the  processing  of  crew 
control  and  information  requests  in  order  to  insure  their 
validity  and  consistency  with  the  current  system  mission,  con¬ 
figuration  and  status.  Mission  authorized  manual  control/ 
override  of  automated  avionics  functions  shall  be  made  possible 
at  all  times.  The  responsibility  for  any  configuration  or 
re  parameterization  required  to  support  manual  operation  rests 
with  the  system  supervisor.  The  sequencing  and  synchronization 
of  major  steps  in  carrying  out  a  mission,  for  example  mission 
mode  changes,  sensor  systems  initialization,  parameterization, 
etc.  shall  be  initiated  and  directed  by  the  supervisor.  The 
remaining  mission  processors,  once  task  definition  loads  and 
parameters  have  been  established  in  response  to  system 
supervisor's  directives  and/or  mission  data  base  content,  shall 
carry  out  the  on-going  control  functions  of  task  sequencing  and 
synchronization  throuqh  task-to-task  communication  services  and 
inter processor  communication  services. 
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3 . ?  . l , 2 . 3  Mission  and  Signal  Data  Processing  Failures 

Notification  of  a  processor  or  i nterproces sor  com¬ 
munications  hardware  fault  will  first  be  made  to  the  executive 
function  in  the  processor.  The  complete  failure  of  a  processor 
or  device  on  the  Mission  Avionics  Multiplex  Bus  shall  be 
detected  by  at  least  the  system  supervisor  through  the  data  bus 
protocol,  revealing  the  lack  of  anticipated  transmission.  This 
detection  is  initially  handled  at  the  executive  level  in  that 
portion  of  the  executive  responsible  for  communications  access. 


In  the  case  of  a  complete  processor  failure,  the 
system  supervisor  shall  Initiate  or  allow  the  system  to  ini¬ 
tiate  in  distributed  implementations  recovery  by  that  procedure 
which,  either  by  preset  design,  or  by  an  algorithmic  determina¬ 
tion,  is  optimal  for  the  preservation  of  mission  functions  and 
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maximum  probability  of  mission  success. 


The  required  recovery  action  shall  consist  of  hard¬ 
ware  reconfiguration,  software  reconfiguration  or  a  combination 
of  the  two.  Upon  loss  of  a  complete  processor  device  or  com¬ 
munications  bus,  the  System  Executive  shall  determine  where 
there  is  available  redundant  or  standby  hardware  to  simply  take 
over  the  failed  element's  function.  If  so,  the  hardware 
reconfiguration  shall  take  place  at  the  executive  level  with 
the  appropriate  noti f i cations, to  the  high  level  functions  in 
all  processors.  In  the  event  such  a  simple  solution  is  not 
possible,  the  system  supervisor  determines  the  required 
hardware/software  reconfiguration  needed  and  initiates 
communications  to  accomplish  the  task.  In  this  way,  changes  in 
mode,  degradation  considerations,  crew  notification  and 
responses,  and  a  complete  knowledge  of  mission  requirements  and 
objectives  may  be  combined  to  best  determine  a  solution  to  the 
problem  presented  by  the  failure.  To  the  fullest  extent  safely 
possible,  the  solution  to  the  reconfiguration  problem  shall  be 
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carried  out  automatically  by  the  system.  Notification  of  the 
reduced  capability  implications  on  mission  objectives  and 
aircraft  safety  shall  be  made  available  to  the  crew. 

When  a  Signal  or  Mission  Data  Processor  fault  is 
detected  local  to  the  processor  which  may  be  fully  recovered 
within  the  processor,  control  and  responsibility  for  recovery 
and  reporting  to  the  system  supervisor  of  the  required  state 
change  shall  rest  with  the  Distributed  Executive  and  applica¬ 
tions  function  and,  with  the  exception  of  notification,  shall 
be  transparent  to  the  remainder  of  the  system.  A  fault  that  is 
determined  to  simply  reduce,  but  not  eliminate,  the  capability 
of  the  processor  shall  be  reported  to  the  supervisor  where 
reconfiguration  determination  shall  then  reside. 

In  those  cases  where  reconfiguration  of  software  is 
undertaken  in  Mission  Data  and  Signal  Processors,  those  pro¬ 
cessors  acquiring  an  altered  complement  of  functions  shall, 
upon  instruction  as  to  the  new  requirements,  initiate  appropri¬ 
ate  total  and  partial  software  loads  from  System  Mass  Memory. 
The  system  supervisor  must  verify  the  new  configuration  upon 
completion  of  the  reconfiguration  and  synchronization  and  the 
re-es tabl i shmen t  of  interrupted  mission  and  sensor  data  pro¬ 
cessing.  Wherever  possible,  functions  not  involved  in  the 
reconfiguration  shall  continue  y  n interrupted. 

3.2. 1.2.4  Vehicle  Management  System  Data  Processor  Failure 

Flight  essential  reliability  requirements  for  the 
VMS  stem  from  the  critical  nature  of  the  majority  of  functions 
provided  there  such  as  flight  controls  actuation,  propulsion 
control,  electrical  distribution  control,  etc.  The  response  to 
failure  of  a  VMS  data  processor  must  therefore  be  swift  and 
certain  resulting  in  an  absolute  minimum,  if  any,  disruption  of 
service.  The  potentially  disastrous  results  of  erroneous 
control  commands  also  require  that  integrated  hardware  and 
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software  measures  be  taken  to  ivnsure  against  software  and 
temporary  error  conditions. 

Detection  of  either  hard  or  soft  failures  in  a  pro¬ 
cessor  shall  result  in  immediate  switchover  to  a  pooled  spare 
VMS  data  processor.  The  responsibility  for  this  response  shall 
be  vested  in  the  executive  software.  The  number  of  levels  of 
redundancy  shall  be  determined  to  meet  the  flight  essential 
reliability  requirements.  In  cases,  if  any,  where  changes  in 
function  served  by  VMS  data  processor  are  dictated  by  failure 
condition,  this  shall  be  accomplished  by  activation  of 
non-volatile  software  routines,  the  entire  software  set  being 
resident  in  each  Non-Volatile  1750A  Processor  Module.  To  guard 
against  loss  of  control  in  the  VMS,  the  control  mechanization 
shall  be  highly  distributed.  If  the  computing  resources 
remaining  after  one  or  more  failures  are  sufficient,  if 
utilized  properly,  to  provide  the  critical  control  functions, 
the  VMS  shall  not  fail  as  a  result  of  the  loss  of  software 
system  control . 

Failure  of  devices,  device  interfaces  or  buses  shall 
he  detected  and  initially  processed  by  the  executive. 
Necessary  notification  to  application  software  for  failure 
conditions  shall  be  initiated  as  a  result  of  executive 
processing. 

3 . 2 . 1 . 2 . 5  Sensor  Systems  Failures 

Control  of  the  sensor/subsystems  both  in  terms  of 
communications  and  in  terms  of  control  command  generation  shall 
reside  in  the  control  processor  of  the  responsible  signal 
processor.  All  systems  originated  sensor  control  command  shall 
be  submitted  to  the  appropriate  signal  processor's  control 
processor  for  passage  to  the  sensor.  Within  the  signal 
processor,  sequencing  of  commands  for  optimization,  resolution 
of  conflicting  commands,  etc.  shall  be  carried  out  and 
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appropriate  notification  sent  to  the  relevant  processor. 
Sensor  failures  shall  be  detected  by  the  Signal  Processor 
Executive.  In  the  event  failure  recovery  is  not  possible,  the 
Signal  Processor  fault  handling  software  shall  notify  the 
system  supervisor  of  the  fault  details  and  shall  notify  all 
processors  expecting  data  from  the  signal  processor  that  the 
sensor  is  unavailable.  Appropriate  responses  to  the  sensor 
loss  shall  be  taken  by  application  software  in  the  notified 
processors.  The  determination  of  system  level  response  to 
sensor  loss  in  the  overall  control / d i rection  of  the  response 
shall  be  carried  out  by  the  system  executive. 

If  a  sensor  system  has  recovery  capability  (for 
example,  switchover  to  a  backup  sensor,  that  may  cause  tempo¬ 
rary  disruption),  established  protocol  within  the  affected 
signal  processor  shall  cause  the  signal  processor  to  become 
aware  of  the  condition.  The  signal  processor  application 
software,  upon  being  notified,  shall  carry  out  any  required 
notification  of  the  dependent  processing  modules  and  notify  the 
system  executive  of  the  disruption.  Otherwise,  the  response  to 
this  level  of  sensor  fault  shall  reside  in  the  signal 
processor. 

3 , 2 . 1 . 2 . 6  System  Mass  Memory  Failures 

Limited  loss  of  memory  capability  without  loss  of 
reloading  capability  shall  be  tolerated  by  the  system  but  shall 
be  transparent  to  all  users  of  memory  access  mechanizations. 
Upon  failure  of  the  active  cystem  Mass  Memory,  the  system  shall 
automatically,  with  transparency  to  the  remainder  of  system, 
redirect  all  memory  accesses  to  the  duplicate  System  Mass 
Memory.  Status  indication  shall  inform  the  system  supervisor 
of  the  change  of  state. 

3.2.2  P  hy s i ca 1  C  ha  ra  c  ter  1 s  t i cs 
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3 .  2 . 2 .  1  Functional  Partitioning 

The  PAVE  PILLAR  core  avionics  shall  be  functionally 
partitioned  into  plug-in  line  replaceable  modules.  The  line 
replaceable  modules  may  be  installed  in  line  replaceable 
assemblies  and/or  integrated  rack:. 

3. P.2. 2  Size 

The  PAVE  PILLAR  common  line  replaceable  module  shall 
be  mechanically  compatible  with  three-ouarter  ATR  size.  (See 
Appendix  A  -  General  Specification  for  3/4  ATR  Module.) 

3.2.3  Reliability 

The  PAVE  PILLAR  avionics  system  shall  be  designed  to 
support  a  mean  time  between  critical  failure  of  70  hours.  Mean 
time  between  critical  failure  is  the  average  operating  time 
betweert  critical  failure.  A  critical  failure  is  a  failure  of 
an  essential  subsystem  and  includes  exceeding  its  specified 
allowable  degradation  of  essential  subsystem  functions. 

3 . 2 . A  Maintainability 

3 . 2 . 4 .  i  mean  Time  to  Repair  Critical  Functions  r'HTTRCFl 

PAVE  PILLAR  system  shall  have  a  mean  time  to  repair 
critical  functions  of  1.25  hours.  The  mean  time  to  repair  a 
critical  function  includes  ?1  turn  on  and  stabilization,  21 
fault  verification,  31  on-equipment  troubleshooting  time,  4) 
repair,  5)  functional  checkout,  6)  turn  off  and  secure. 

3 .  ? ,  4 . 2  On-Equi  pipg^tTroubjeshooti  ng  Time 

The  goal  for  on-equipment  troubleshooting  time  is  10 
minutes  or  less.  On-equipment  troubleshooting  time  is  the 
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average  time  required  to  Isolate  malfunctions  using  BIT  support 
equipment  and/or  tech  orders  to  the  lowest  level  Indenture 
where  corrective  maintenance  can  be  performed. 

3. 2. 4. 3  Percent  Fault  Detection 


The  goal  for  the  PAVE  PILLAR  system  is  99%  fault 
detection.  The  percent  fault  detection  is  determined  by  the 
following  computation.  The  number  of  verified  failures  de¬ 
tected  by  BIT  divided  by  the  total  number  of  verified  failures 
detected  by  all  other  methods.  A  verified  failure  is  a  condi¬ 
tion  where  1)  equipment  performance,  including  bit  performance, 
is  less  than  that  required  by  specifications,  and  ?)  corrective 
action  is  required  to  restore  equipment  performance.  The  fault 
detection  percentage  applies  to  all  possible  faults  as  weighted 
by  the  relative  rates.  This  format  assumes  that  a  requirement 
already  exists  for  100%  diagnostic  capability. 

3. 2. 4. 4  Percent  Fault  Isolation 


The  goal  for  the  PAVE  PILLAR  avionics  is  98%  fault 
isolation.  Percent  fault  isolation  is  computed  by  the  follow¬ 
ing  method.  The  number  of  malfunctions  properly  isolated  by 
bit  divided  by  the  number  of  verified  failures  detected  by  bit. 
Proper  isolation  is  defined  as  unambiguous  identification  of  a 
single  unit  that  is  of  the  lowest  level  of  assembly  that  is 
defined  for  removal  from  the  end  item. 

3.2.5  Avai lability 

3.2.5. 1  Sortie  Rate 


The  goal  for  sortie  rate  per  day  is  4.5  or  greater. 
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3 . 2 . 5  .  2  Abort  Rate 

The  goal  for  abort  rate  shall  be  1%  or  less. 

3 . 2 . 5 . 3  T  ime 

The  PAVE  PILLAR  design  will  impose  no  system  re¬ 
quirements  which  would  preclude  a  combat  turnaround  time  of  15 
minutes.  Combat  turnaround  time  is  defined  as  the  elapsed  time 
required  to  inspect,  clean,  service  fuel,  oil,  hydraulics,  and 
other  consummabl es ,  re-arm,  load,  and  prepare  to  relaunch  an 
aircraft  returning  in  a  mission  capable  status.  This  time  may 
also  include  a  re-key  or  update  to  the  COMSEC/TRANSEC  systems. 
Time  begins  when  the  aircraft  stops  taxiing  and  ends  when  the 
aircraft  begins  taxiing  toward  the  runway  for  a  subsequent 
sortie. 

3 . 2 . 5 . 4  Total  Non-Mission  Capable  for  Maintenance  of 
Avionics 

The  total  non-mission  capable  for  maintenance  of 
avionics  shall  not  exceed  1,2%.  Total  non-mission  capable  for 
maintenance  of  avionics  is  the  cumulative  percentage  (based  on 
24  hour  clock)  of  aircraft  that  are  non-mission  capable  because 
of  avionics  maintenance. 

3 . 2 . 5 . 5  Total  Non-Mission  Capable  for  Supply  of  Av ionics 

Total  non-mission  capable  for  supply  of  avionics 
shall  not  exceed  0.2%.  Total  non -mission  capable  for  supply  of 
avionics  is  the  cumulative  percentage  based  on  the  24  hour 
clock  of  aircraft  that  are  non-mission  capable  because  they 
need  avionics  parts. 

3.2.6  ]E  f  f  e  c  tj  ven  e  s  s_Mo  d  e2^  (Not  Applicable) 
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3.2.7  Fnv  1 ironmenta 1  Conditions  (Not  Applicable! 

3.2.8  Nuclear  Control  (Not  Applicable) 

3.2.9  Transportabi 1 i ty  (Not  Applicable) 

3 . 3  Design  and  Construction 

3.3.1  Material,  Parts  and  Processes 

The  PAVE  PILLAR  Avionics  shall  be  designed  to  take 
maximum  advantage  of  VHSIC  and  fiber  optic  technology, 

3.3.2  Electromagnetic  Compati bi 1 i ty  (Not  Applicable) 

3.3.3  Nameplate  and  Product  Marking  (Not  Applicable! 

3.3.4  Workmanshi p  (Not  Applicable) 

3.3.5  Interchangeabi 1 i ty 

The  Common  Modules  which  make  up  the  PAVE  PILLAR 
Avionics  (see  Section  6.1)  will  be  interchangeable  within  type 
classes,  i.e.,  VHSIC  1750A  Processors,  Avionics  Bus  Interface, 

A  4  yv 

c  u.  • 

3.3.6  S a f e t v  (Not  Applicable! 

3.3.7  Human  Engineering 

All  man-machine  Interactions  shall  be  desiqned  so  as 
to  provide  maximum  off-loading  of  tasks  which  can  be  accom¬ 
plished  by  a  computer  system  and  to  place  minimum  interpretive 
demands  on  the  crew.  The  crew  should  be  presented  with  clear, 
concise,  easily  Interpreted  display  data,  prompts,  selection 
ranges,  etc.  and  a  minimum  of  human  intervention  in  mission 
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control  functions  should  be  required.  Nevertheless,  mission- 
authorized  manual  control/override  of  automated  avionics 
functions  shall  be  made  possible  at  all  times;  the  responsibil¬ 
ity  for  any  reconfiguration  or'  reparameterizat.ion  required  to 
support  manual  operations  rests  with  the  Mission  Supervisor. 

3.3.8  Pro£rar'’  Design 

3 . 3 . 8 . 1  Higher  Or d e r  _  _L. a ngu a cje / Run  T  i rne_S u gj)o r  t  Sy s  tern 

The  Operational  Flight  Program  (OFF)  will  be  de¬ 
veloped  in  accordance  with  the  requirements  of  the  Ada  (ANSI/ 
MIL-STP-1R15A)  programming  language,  unless  otherwise  approved 
by  the  Government. 

3 . 3 .8 . 2  S.£lAw£I£_Il£vel  oprnent  Svstem/Pesicin  Ai^S 

Software  development  for  operational  flight  programs 
will  be  accomplished  using  an  integrated  Ada  Programming  Sup¬ 
port  Environment  (APSF)  which  supports  a  standard  set  of  pro¬ 
gramming  tools  (editor,  compiler,  linker,  loader,  debugger]  in 
addition  to  an  Ada  based  program  design  language  (PPL)  for  use 
in  the  design  stage  of  the  software  development.  The  software 
development  system  will  support  the  MII.-STD-1750A  data 
processor  instruction  set  as  a  target  machine. 

3 . 3 . 8 . 3  A t^nd£rd_^n ter f a ces_Re£uAremen t 

All  PAVF  PILLAR  application  software  will  observe 
rigid  interfaces  between  tasks.  Interfaces  between  functions 
will  also  observe  inter-task  interface  restrictions,  and  will 
utilize  such  interfaces  only  as  are  consistent  with  functional 
isolation  between  functions.  The  trade-off  between  functional 
isolation  and  the  need  for  integration  functions  to  satisfy 
PAVE  PILLAR  reliability  requirements  is  simplified  by  the 
application  of  rigidly  enforced  interface  definitions. 
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Four  general  classes  of  interface  will  exist: 
interfaces  between  one  executions!  level  and  another,  as 
typified  by  a  subroutine  call,  which  exist  within  a  task; 
interfaces  between  two  tasks  which  constitute  some  portion  of  a 
major  function;  interfaces  between  two  functions;  and 
interfaces  between  software  executing  in  two  or  more 
processors.  The  last  class  of  interfaces  can  coe  ist  with  any 
cf  the  other  three,  and  will  typically  coexi  t  with 
inter- function  interfaces.  These  classes  are  illustrated  in 
Figure  3. 3, 8. 3-1. 

The  least  restricted  class  of  interfaces  Is  the 
class  of  inter-module  interfaces.  These  interfaces  must  not 
transcend  task  boundaries,  or  they  become  inter-task  inter¬ 
faces.  The  general  rule  for  inter-module  interfaces  are 
defined  by  the  programming  language,  or  by  convention  for 
assembly  language  modules.  The  application  software  will  be 
written  in  accordance  with  well  defined  inter-module  inter¬ 
faces,  which  will  be  specified  to  enhance  modularity  by  maximum 
suitable  use  of  parametric  and  table-driven  techniques. 

Inter-task  interfaces  are  more  restrictive  than 
inter-module  interfaces.  In  this  context,  the  tasks  are  part 
of  the  same  function,  since  an  interface  between  tasks  of  two 
different  functions  are  i  n te r- f unc 1 1  on  interfaces.  Tnter-task 
interfaces  are  not  permitted  to  be  directly  executed,  but 
instead  require  executable  intervention.  Consequently,  this 
class  of  interfaces  is  restricted  to  the  use  of  logical  events 
and  data  base  accesses.  The  exception  to  this  is  the  interface 
with  the  Kernel  executive,  which  for  this  purpose  is  considered 
to  be  a  part  of  every  task.  Thus,  a  task  can  call  the 
executive  using  inter- module  techniques,  and  the  executive  can 
perform  the  requested  operation  on  another  task,  also  using 
inter-module  techniques  since  the  executive  is  a  part  of  both 
tasks.  A  task  thus  affects  the  operation  of  another  task  by  a 
logical  operation.  The  interfaces  between  the  tasks  and  the 
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executive  are,  therefore,  required  to  be  well  defined,  riqidly 
applied,  and  standardized  for  all  tasks.  These  interfaces  are 
further  discussed  in  Section  6.3. 

The  class  of  inter-function  interfaces  is  more  re¬ 
strictive  than  inter-task  interfaces.  The  interfaces  represent 
a  trade-off  between  the  need  for  functional  integration.  Func¬ 
tional  isolation,  at  the  Ideal,  demands  a  total  separation  of 
functions.  The  ideal  for  Integration  demands  use  the  maximum 
amount  of  interchange  between  functions  to  permit  liberal 
transfer  of  information.  The  use  of  data  base  information  as 
the  transfer  vehicle  does  not  seriously  denigrate  Isolation 
while  greatly  enhancing  integration  from  the  fully  isolated 
condition.  Likewise,  logical  effects  can  be  useful  as  long  as 
the  vehicle  for  transfer  of  the  effect  is  structured  to  provide 
the  maximum  amount  of  isolation.  Direct  interface  defeats 
isolation  entirely.  It,  therefore,  appears  that  the 
inter-function/inter-task  classes  should  be  minimized  for  the 
former  and  freely  permitted  for  the  latter. 

Inter-processor  Interfaces  can  occur  for  any  other 
class  of  Interface.  It  is  highly  inefficient  for  an  inter¬ 
module  Interface  to  be  Implemented  between  processors  due  to 
the  overhead  associated  with  coordinating  control  and  data  base 
transfer  between  processors.  This  will,  therefore,  not  be 
permitted  for  application  software.  As  discussed  earlier-,  to 
permit  inter-function  interfaces  is  functionally  to  provide  the 
capability  for  inter-task  interfaces.  Inter-function  interface 
capability  is  required  In  an  inter-processor  environment.  It 
Is  recommended  that  i n te r-f unc t i on/ i n ter- proces sor  Interfaces 
be  restricted  by  convention  to  minimize  the  amount  of  data 
necessary  to  be  transferred  in  support  of  the  interface.  The 
capability  will  be  provided,  with  the  limitation  being 
conventional  and  subject  to  pe-rrni ssebl e  partitioning  details. 
All  inter- process  or  interfaces  will  be  effected  by  intervention 
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of  both  the  Kernel  and  Distributed  Executives  of  the  respective 
processors . 


3.4  Documentation 


Elements  which  require  additional  documentation  in¬ 
clude  as  a  minimum  the  1750  Processor,  Common  Signal  Processor, 
High  Speed  Data  Bus,  Switch  Assemblies,  and  other  ma.ior  archi¬ 
tecture  elements. 

3 . 5  l o  gist i c  s 

The  Avionics  System  shall  be  desiqned  with  a  primary 
qoal  of  minimizing  the  costs  of  operation  and  maintenance  and 
to  enhance  the  accomplishment  of  required  maintenance. 

3.5.1  Mai  n  t e n  a  n c e_K n vj^ r o n me  n  t 


The  Avionics  System  will  be  designed  to  support 
deployment  to  sites  with  damaged,  limited  or  non-existent 
support  facilities. 

3. 5. 1.1  tli!.i!lienarice_ Concept. 

The  PAVE  PILLAR  Maintenance  Concept  is  based  upon 
two  levels  of  maintenance:  On-Equipment  (aircraft!  and  Off- 
Equipment  (depot), 

3 . 5 . 1 . 1 . 1  Organizational  Level  Maintenance  Requirements 

A,  Maintenance  shall  consist  of  repair  by  replacement  of 
faulty/failed  Items. 

11  On-equipment  repairs  shall  be  performed  on  miscel¬ 
laneous  wiring,  cabling,  and  connectors. 
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8.  Packaging  and  modularization  of  system  items  'shall  be  de¬ 
signed  to  ensure  that  maintenance  personnel  are  able  to 
remove  and  return  faulty/failed  items  to  depot  repair 
faci 1 i ties , 

C.  The  primary  fault  detection  and  isolation  (FDI)  functions 
for  corrective  maintenance  and  system  readiness  tests 
shall  be  provided  by  a  combination  of  on-board  diagnostics 
and  bu 1 1 t-i n- tes t  (BIT). 

1)  Provisions  for  manual  testing  with  in-place  common 
test  equipment  shall  be  provided  when  required. 

2 )  On-board  diagnostics  and  BIT  shall  include  automated 
maintenance  aids  to  direct  maintenance  personnel  to 
faulty/failed  items  with  clear,  concise  statements 
describing  the  item,  the  type  of  fault  or  failure, 
and  sequence  of  events  in  time,  and  the  location  of 
the  item  with  text  and  graphic  line  drawings  when 
required. 

3)  On-board  diagnostics  and  BIT  results  shall  be  re¬ 
corded  in  a  nori-volatile  medium  for  recall  capabil¬ 
ity  inflight  or  postflight  and  transfer  capability 
to  ground  maintenance  facilities. 

0,  No  peculiar  support  equipment  shall  he  required  to  com¬ 
plete  organization  level  maintenance. 

E.  No  preventive  (scheduled)  maintenance  shall  be  required 
except  system  readiness  tests. 

3 . 5 . 1 . 1 .  ?  Depo t._Le ve l__Ma j_n terta n ce_Re a uj^remen t s 

A,  Depot  level  maintenance  facilities  shall  be  responsible 
for  the  following  actions: 
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1)  Repair  the  items  f orwarded  from  organizational 
facilities  and  return  them  to  the  supply  system. 

?)  Condemn  the  item  and  notify  supply  of  the 
disposition, 

3.5.?  Supply  Support 

Supply  Support  will  be  tailored  to  Military  Supply 
and  Transportati on  Evaluation  Procedures  (MILSTEP),  The 
Organizational  Maintenance  Unit  will  be  authorized  Spare  Parts 
based  upon  the  two  level  maintenance  concept.  Supply  levels 
will  be  authorized  based  upon  usage  factors  and  pipeline  times 
plus  a  safety  level.  A  supply  of  Line  Replaceable  Modules  will 
be  authorized. 

3.5.3  Facilities  (Not  Applicable! 

3.5.4  Cost 

The  PAVE  PILLAR  concept  requires  an  overall  lower 
life  cycle  cost  with  respect  to  current  avionics  suites.  The 
reouired  characteristics  include: 


u  i  ueve  ni|iiny  lei.  rmuiuyy  a  y  jj  i 


i ,  e  ,  ,  V  M  S I  C  . 


o  Standardization  of  data  processors  (MIL-STD- 
1  7 50 A ) .  Multiplex  Rus  Communications  (MIL-STO-1553B  and  Hiqh 
Speed  Data  Rus),  and  operating  system  and  application  software 
(MIL  -  STD- 181 5A ) . 


o  Modularization  and  replication  of  modules 
across  functions,  as  well  as  to  achieve  redundancy  within  a 
function.  Modularization  is  carried  to  the  lowest  possible 
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level  to  facilitate  remove  and  replace  maintenance  in  a  two- 
level  maintenance  concept. 

o  High  reliability  specifications  for  critical 
system  components. 

o  Fault  detection  and  isolation  through  on-board 
diagnostics  and  built-in-test  (BIT). 

o  Ease  of  Pre-Planned  Product  Improvement  (P3P. 

3.6  Personnel  and  Training  (Not  Applicable! 

3 . 7  Functional  Area  Characteristics 

The  PAVE  PILLAR  core  avionics  is  partitioned  into 
four  functional  groups: 

(1)  Digital  Signal  Processing 

(2)  Mission  Processing 

(3)  Vehicle  Management  System 

(4)  Avionics  System  Control. 

To  gain  maximum  commonality  across  functional  areas 
and  to  minimize  the  number  of  Interface  module  types,  all 
system  busses  as  a  class  and  all  system  data  distribution 
networks  as  a  class  should  be  of  a  common  functional  type.  All 
communication  paths  between  system  elements  should  employ  fiber 
optic  media. 

The  common  components  and  their  internal  interfaces 
are  described  in  the  following  subsections:  Data  Processors, 
System  Mass  Memory,  Mission  Avionics  Bus,  Block  Transfer  Bus, 
Vehicle  Management  System  Bus,  Signal  Processor,  Sensor  Data 
Distribution  Network,  Video  Data  Distribution  Network,  System 
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Executive,  Kernel  Executive  and  Distributed  Executive.  See 
Section  6,1  for  a  description  of  individual  modules. 

3.7.1  Data  Processors 

The  Data  Processors  perform  the  general  purpose 
computational  processing  that  does  not  require  unique  I/O 
interfaces,  dedicated  hardware  functions  or  excessive  through¬ 
put  rate.  Each  processor  will  conform  to  the  MIL-STD-  1 7 5 0 A 
Instruction  Set  Architecture  MSA).  Each  data  processor  will 
contain  one  or  more  V1750A  processor  modules  on  the  Common 
Backplane  Communication  Bus. 

3.7. 1.1  Data  Processor  ..Diagrams 

The  Data  Processsor  for  the  Mission  Processing  Area 
and  Vehicle  Management  Area  are  shown  in  Figs.  3.7. 1-1  and 
3.7, 1-2. 

3 . 7 . 1 . 2  Operating  System 


Each  Data  Processor's  Operating  System  will  be 
comprised  of  a  Distributed  Executive  and  a  Kernel  Executive. 

3. 7. 1.3  Inter-Module  Communications 


The  interface  between  modules  shall  be  provided  bv 
the  integrated  rack.  The  integrated  rack  shall  provide  a  com¬ 
mon  backplane  which  shall  interconnect  the  modules. 

3 , 7 . 1 .  3  . 1  in  ter-Modu2£_Commun2ca  t2ons^_Rus_£PNRu2_) 

The  Pi-Bus  shall  be  the  primary  general  purpose 
parallel  backplane  bus  which  interconnects  sets  of  modules 
performing  a  common  function  (i.e..  Data  Processor).  The 
Pi-Bus  Pave  Pillar  implementation  shall  be  16  data  bits  with 
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Figure  3.7.1-1  DATA  PROCESSOR  MODULAR  STRUCTURE 
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error  detection.  ( See  Appendix  B  -  VHS^C _ Pha_s_e _ ? 

I nteroperabi 1 i ty  Standards,  Pi-Bus  Specification )  The  Pi-Bus 
shall  support  the  transfer  of  12.5  million  words  per  second. 
Two  Pi-Buses  shall  be  employed  for  redundancy  in  case  of 
primary  bus  failure. 

3. 7. 1,3. 2  Test  and  Maintenance  Bus  (TM-Bus) 


The  Test  and  Maintenance  Bus  shall  be  a  serial 
4-signal  backplane  bus  which  interconnects  sets  of  modules 

performing  a  common  function  (See  Appendix  C  -  VHSIC  Phase _ 2 

Interoperability  Standards  TM-Bus  Specification) .  The  primary 
purpose  of  the  TM-Bus  is  to  provide  a  common  means  for 
performing  test  and  maintenance  of  modules  at  the  circuit  level 
at  the  depot  or  factory.  It  is  also  intended  to  be  used  to 
support  on-equipment  maintenance  to  detect  and  isolate  faults 
to  a  module.  The  TM-Rus  may  be  used  operationally  to  perform 
fault  detection  and  isolation  on  those  modules  designed  to  use 
the  TM-Bus  in  that  manner.  It  shall  allow  the  module 
designated  as  a  maintenance  controller  (the  VHSIC  1 7 5 0 A  CPU 
module  shall  have  maintenance  controller  capability!  to 
initiate/command  self  test  functions  on  all  of  the  modules,  as 
well  as  support  the  collection  of  self  test  status  information 


•V  V\  H  rw*  lb/'  4-  4- 
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3.7,2  t em_Ma  is  s_M emo r^ 

The  System  Mass  Memory  shall  be  non-volatile  and 
have  both  read/write  capabilities.  The  System  Mass  Memory 
shall  be  able  to  act  as  a  logical  file  oriented  device  with  an 
intelligent  controller  interface  as  well  as  a  random  access 
storage  device. 
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3 . 7 . 2 . 1  System_Mass  Memory  Diagram 

The  System  Mass  Memory  Diagram  is  shown  in  Figure 

3. 7. 2. 1-1. 

3. 7. 2. 2  Inter-Module  Communications 


The  interface  between  modules  shall  be  provided  by 
the  integrated  rack.  The  integrated  rack  shall  provide  a 
common  back  plane  which  shall  interconnect  the  modules. 

3. 7. 2. 2.1  Inter-Module  Communications  Bus  f  PI -Bus  1 


The  PI-Bus  shall  be  the  primary  general  purpose 
parallel  backplane  bus  which  interconnects  sets  of  modules 
performing  a  common  function  (i.e.,  Data  Processor).  The 
PI-Bus  Pave  Pillar  implementation  shall  be  16  data  bits  with 

error  detection.  (See  Appendix  B  -  VHSj_C Phase 2 

lllteroperabjl  i  ty_  Standards  ,  PI-Bus.  Specification  .)  The  PI-Bus 
shall  support  the  transfer  of  12.5  million  words  per  second. 
Two  Pi-Buses  shall  be  employed  for  redundancy  in  case  of 
primary  bus  failures. 

3. 7. 2. 2. 2  Test  and  Maintenance  Bus  (TM-Pus) 


The  Test  and  Maintenance  Bus  shall  be  a  serial 
4-signal  backplane  bus  which  interconnects  sets  of  modules 
performing  a  common  function  (See  Appendix  C  -  VHSK_ £haj>e__? 
Interoperability  Standards  TM-Bus  Specifica  ti_on ) .  The  primary 
purpose  of  the  TM-Bus  is  to  provide  a  common  means  for 
performing  test  and  maintenance  of  modules  at  the  circuit  level 
at  the  depot  or  factory.  It  is  also  intended  to  be  used  to 
support  on-equipment  maintenance  to  detect  and  isolate  faults 
to  a  module.  The  TM-Bus  may  be  used  operationa 1 ly  to  perform 
fault  detection  and  isolation  on  those  modules  designed  to  use 
the  TM-Bus  in  that  manner.  It  shall  allow  the  module 
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designated  as  a  maintenance  controller  (the  VHSIC  1750A  CPU 
module  shall  have  maintenance  controller  capability)  to 
initiate/command  self  test  functions  on  all  of  the  modules,  as 
well  as  support  the  collection  of  self  test  status  information 
and  make  that  status  available  external  to  the  functional  area, 

3.7.3  Universal  Remote  Terminals 


The  Universal  Remote  Terminals  shall  provide:  (1) 
interfaces  to  non-core  devices  such  as  data  recorders,  data 
transport  units  and  helmet  voice/sight  units,  (?)  a  method  of 
interfacing  standard  test  equipment  to  the  on-board  computer 
systems  using  IEEE  488  standard  test  equipment  buses,  and  (3)  a 
MI L-STD-1553B  interface  capability. 

3 . 7 . 3 .  1  System  H i ag  ram 

A  typical  Universal  Remote  terminal  is  shown  in 
Figure  3. 7. 3-1. 

3.7.3. ?  Inter-Module  Communications 


The  interface  between  modules  shall  be  provided  by 
the  integrated  rack.  The  integrated  rack  shall  provide  a  com¬ 
mon  back  plane  which  shall  interconnect  the  modules. 

3.7.3.?. 1  Inter-Module  Communications  Pus  (PI -Bus) 


The  Pi-Bus  shall  be  the  primary  general  purpose 
parallel  backplane  bus  which  interconnects  sets  of  modules 
performing  a  common  function  (i.e.,  Peta  Processor).  The 
Pi-Bus  Pave  Pillar  implementation  shall  be  16  data  bits  with 

error  detection.  (See  Appendix  B  -  VHSJ_C Phas_e ? 

Interopera bi 1 i ty  Standards,  Pi-Bus  Specification.)  The  PI -Bus 
shall  support  the  transfer  of  1?.5  million  words  per  second. 
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Two  PI-Busgs  shall  be  employed  for  redundancy  in  case  of 
pr i ma rv  bus  failure. 

3. 7. 3. 2. 2  Test  a££lJK«n  ntenance_Bu£_£TM-Buj>  j 

The  Test  and  Maintenance  Bus  shall  be  a  serial 
4-signal  backplane  bus  which  interconnects  sets  of  modules 
performing  a  common  function  ( See  Appendix  C  -  VHS2C_J^h_ajse 
Interoperability  Standards  TM-Bus  Specification .  The  primary 
purpose  of  the  TM-Bus  is  to  provide  a  common  means  for 
performing  test  and  maintenance  of  modules  at  the  curcuit  level 
at  the  depot  or  factory.  It  is  also  intended  to  be  used  to 
support  on-equipment  maintenance  to  detect  and  isolate  faults 
to  a  module.  The  TM-Bus  may  be  used  operationally  to  perform 
fault  detection  and  isolation  on  those  modules  designed  to  use 
the  TM-Bus  in  that  manner.  It  shall  allow  the  module 
designated  as  a  maintenance  controller  (the  VHSIC  1750A  CPU 
module  shall  have  maintenance  controller  capability)  to 
initiate/command  self  test  functions  on  all  of  the  modules,  as 
well  as  support  the  collection  of  self  test  status  information 
and  make  that  status  available  external  to  the  functional  area. 

3.7.4  Xl££i£s_M  u  J_  tj.£  l_e  x_Bu  s 

The  Mission  Avionics  Multiplex  Pus  shall  consist  of 
two  independent/redundant  buses.  Fach  bus  will  have  a  minimum 
effective  data  transmission  rate  of  2f)  MBPS. 

3 . 7 . 4 . 1  l££2l££Z 

The  Mission  Avionics  Multiplex  Bus  shall  use  a 
logical  multidrop  linear  bus  structure.  The  implementation 
shall  be  capable  of  supporting  64  physically  separate  remote 
terminals. 


SPA  90099001  A 
16  January  1987 


3 . 7 . 4 . 2  Protocol 

The  Mission  Avionics  Multiplex  Rus  shall  provide  the 
following  protocol: 

-  Physical  (Terminal)  and  logical  (content) 
Addressing  Modes 

-  Synchronous  and  Asynchronous  Messages 

-  Rounded  latencies 

-  Lost  message  determination 

-  Terminal  Insertion  and  removal 

-  System  Initialization 

(See  Appendix  D  -  High  Speed  Data  Rus  System  Specification). 

3. 7. 4. 3  Control 

The  Mission  Avionics  Multiplex  Rus  shall  implement  a 
distributed  control  mechanism.  The  control  mechanism  shall 
support  asynchronous  and  priority  messages.  The  control 
mechanism  shall  be  deterministic. 


3 . 7 . 4 . 4  Interface  Characteristic 

Fach  unit  connected  to  the  Mission  Avionics  Multi¬ 
plex  Rus  shall  provide  an  Avionics  Pus  Interface  Module. 

3.7.4. 5  r  a  c  to  r_i  s  t  j_cs 

The  preferred  media  for  the  Mission  Avionics 
Multiplex  Rus  shall  be  fiber  optics  with  a  passive, 
transmissive  star  coupler. 


3. 7. 4. 6  FauJ 


drop  out, 


All  fault  recovery  such  as  lost  tokens,  terminal 
lost  media,  lost  message,  etc.,  shall  recover  within 
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20  milliseconds.  Faults  requiring  more  recovery  time  shall  be 
deemed  not  recoverable. 

3. 7. 4. 7  Nuclear  Hardness 


The  VHSIC  Phase  I  nuclear  hardness  requirements 
should  be  used. 

3.7,5  B lock  Transfer  Bus 

The  Block  Transfer  Bus  shall  consist  of  two  inde¬ 
pendent/redundant  buses.  Each  bus  will  have  a  minimum 
effective  data  transmission  rate  of  20  MBPS. 

3 . 7 . 5 . 1  Xo££l£S.^ 


The  Block  Transfer  Bus  shall  use  a  logical  multidrop 
linear  bus  structure.  The  implementation  shall  be  capable  of 
supporting  64  physically  separate  remote  terminals. 

3 . 7 . 5 . 2  Protocol 

The  Block  Transfer  Bus  shall  provide  the  following 

protocol  : 


-  Physical  (Terminal)  and  logical  ( content) 
Addressing  Modes 

-  Synchronous  and  Asynchronous  Messages 

-  Bounded  latencies 

-  Lost  message  determination 

-  Terminal  Insertion  and  removal 

-  System  initialization 

(See  Appendix  D  -  hi  £h_  Sjpeed_Ha  t  a_Bu  s^_Sys^t  erri_S£ec_i_f  j_££  t  j_on  )  . 
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3 . 7 . 5 . 3  Control 

The  Block  Transfer  Bus  shall  implement  a  distributed 
control  mechanism.  The  control  mechanism  shall  support 
asynchronous  and  priority  messages.  The  control  mechanism 
shall  be  deterministic. 

3. 7. 5.4  Interface  Characteristics 


Each  unit  connected  to  the  Block  Transfer  Bus  shall 
provide  an  Avionics  Bus  Interface  Module. 

3 . 7 . 5 . 5  Physical  Characteristics 

The  preferred  media  for  the  Block  Transfer  Bus  shall 
be  fiber  optic  with  a  passive,  transmissive  star  coupler. 

3 . 7 . 5 . 6  Fault  Recovery 

All  fault  recovery  such  as  lost  tokens,  terminal 
drop  out,  lost  media,  lost  message,  etc.,  shall  recover  within 
?0  milliseconds.  Faults  requiring  more  recovery  time  shall  be 
deemed  not  recoverable. 

3. 7. 5. 7  Nuclear  Hardness 


The  VHSIC  Phase  I  nuclear  hardness  requirements 
should  be  used. 

3.7.6  Vehicle  Management  System  Multiplex  Bus 

The  Vehicle  Management  System  Multiplex  Bus  shall 
support  four  independent  buses.  Each  bus  will  have  a  minimum 
effective  data  transmission  rate  of  20  MBPS. 
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3 . 7 . 6 . 1  Topology 

The  Vehicle  Management  System  Multiplex  Bus  shall 
use  a  logical  multidrop  linear  bus  structure.  The 
implementation  shall  be  capable  of  supporting  64  physical 
separate  remote  terminals. 

3 . 7 . 6 . 2  Protocol 

The  Vehicle  Management  System  Multiplex  Bus  shall 
provide  the  following  protocol: 

-  Physical  (Terminal)  and  logical  (content) 
Addressing  Modes 

-  Synchronous  and  Asynchronous  Messages 

-  Bounded  latencies 

-  Lost  message  determination 

-  Terminal  Insertion  and  removal 

-  System  Initialization 

Appendix  D  -  High  Speed  Data  Bus  Protocol  describes  the  bus 
protocol . 

3 . 7 . 6 . 3  Control 

The  Vehicle  Management  System  Multiplex  Bus  shall 
implement  a  distributed  Control  Mechanism.  The  Control 
Mechanism  shall  support  asynchronous  and  priority  messages. 
The  control  mechanism  shall  be  deterministic. 

3 . 7 . 6 . 4  Interface  Characteristics 

Each  unit  connected  to  the  Vehicle  Management 
Multiplex  Bus  shall  provide  two  Avionic  Bus  Interface  Modules. 
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3 . 7 . 6 . 5  Physical  Characteristics 


The  preferred  media  for  the  Vehicle  Management 
System  Multiple  Bus  shall  be  fiber  optic  transmission  media 
with  a  passive,  transmissive  star  coupler. 


3. 7. 6. 6  Fault  Recovery 


All  fault  recovery  such  as  lost  tokens,  terminal 
drop  out,  lost  media,  lost  messape,  etc.  shall  recover  within 
20  milliseconds.  Faults  requiring  more  recovery  time  shall  be 
deemed  not  recoverable. 


3. 7. 6. 7  Nuclear  Hardness 


The  VHSIC  Phase  I  nuclear  hardness  requi remen ts 
should  be  used. 


3.7.7 


Common  Signal  Processor  (CSPl 


The  Common  Signal  Processor  consists  of  modular 
resources  that  perform  the  signal  processing  function  for 
Padar,  EW,  Image  and  CNI  Processing.  Table  3. 7. 7-1  lists 
typical  signal  processing  algorithms  the  CSP  shall  be  capable 
of  implementing  in  real  time . 


3 . 7 . 7 . 1  Common  Signal  Processor  Diagram 


The  Common  Signal  Processor  is  shown  in  Figure 


3. 7. 7. 1-1 


3. 7. 7. 2  Inter-Module  Communications 


The  interface  between  modules  shall  be  provided  by 
the  integrated  rack.  The  integrated  rack  shall  provide  a  com¬ 
mon  back  plane  which  shall  integrate  the  modules. 


spa  90099001  a 

16  January  1387 


TARLE  3. 7. 7-1 

TYPICAL  SIGNAL  PROCESSING  FUNCTIONS 


RADAR 


F FT ,  FFT” 1 

Coordinate  Transformation 
Complex  Mul ti ply 
Complex  Aid 

Floating-Point  Multiply/Add 

Lookup  Multiply 

Norma  1 i ze  Divide 

Averag i ng 

Thresholding 

Vector /Matrix  Operations 

Matrix  Transpose 

Chinese  Remainder 

Logarithm 

Cancel  1 er 

Compare 

Max /Mi n 

Accumu 1  ate 

Trig  Functions  (Weighting! 
Sliding  Window 

r  a  n  i/  a  1  1 1  f  *1  y\ 


U  W  1 1  I  W  I  U  L  I  Ufl 


FIR  Filter 
IIR  Filter 


Table  Lookup 
Polynomial  Evaluation 
Chinese  Remainder 
Associative  Memory 
Hash i ng 

Decision  Trees 
Window  Compares 
Multiparameter  Correlation 
Statistical  Filter  (e,q.,  Kalman! 
Dynamic  Memory  Assignment 
Demodulation  Algorithms 
Statistics  (Mean,  Standard 
Deviation) 

Adaptive  Lattice  Filter 
Discrete  Convolution 
Recursive  Filtering 

n  *1  r  /»  ITi  A  4'  A  f  /t  r  «  M  A  T  iVi 

IM  v  I  cue  V  W  J  lilt;  C  I  U  I  I  3  '  Ul  J  H 

Wa 1 s h -Ha dama rd  Transform 

Hear  Transform 

Gain  and  Bias  Correction 

Direct  Correlation 

X-Form  Correlation 

Gradient  Operator 

Kirsch  Edge  Filter 

Sobel  Edge  Filter 

Cubic  Convolution  Resampling 

Histogram  Modification 
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3 . 7 . 7 . 2 . 1  Inter-Module  Communications  Pus  (Pi-Bus) 

The  Pi-Bus  shall  be  the  primary  general  purpose 
parallel  backplane  bus  which  interconnects  sets  of  modules 
performing  a  common  function  (i.e.,  Data  Processor).  The 
Pi-Bus  Pave  Pillar  implementation  shall  be  16  data  bits  with 

error  detection.  (See  Appendix  B  -  VHS_IC Phase 2 

Tnteroperabi 1 i ty  S tan  da rds  ,  Pi-Bus  Specification.)  The  PI -Bus 
shall  support  the  transfer  of  12.5  million  words  per  second. 
Two  PI-Buscs  shall  be  employed  for  redundancy  in  case  of 
primary  bus  failure. 

3. 7.  7. 2. 2  Da  ta_F_[ow_ Network 

The  internal  Data  Flow  Network  provides  high  speed 
data  transmission  paths  between  modules  performing  a  common 
function  (i.e.,  signal  processing).  Trie  Data  Flow  Network 
shall  be  a  network  switching  concept  which  supports 
simultaneous  interconnections  of  any  independent,  pair  of 
sources  and  destinations  of  data  connected  to  the  network. 
Control  of  the  network  is  decentralized:  the  initiating  module 
determines  the  path  through  the  network  and  the  target  module 
for  the  transmission.  The  network  is  optimized  for  block 
transfers;  it  may  be  implemented  with  a  variety  of  path  widths, 
including  16-bit  and  32-bit  data  paths.  The  baseline  word  width 
is  32  bits.  The  transfer  rate  goal  is  25  million  words  per 
second.  The  networks  may  be  implemented  with  a  variety  of 
numbers  of  ports;  the  maximum  number  shall  be  at  least  24 
ports,  supporting  up  to  12  parallel  transmissions.  Any  port 
may  be  connected  to  any  other  port. 

3  .  7 , 7 . 2 . 3  T  e  s  t_a  n  d_M a_i_ n  t e  n  a  n  c  e_ B  u  s _ £ TM_-  8 u  s_)_ 

The  Test  and  Maintenance  Bus  shall  be  a  serial 
4-signal  backplane  bus  which  interconnects  sets  of  modules 
performing  a  common  function  (See  Appendix  C  -  V H SJ_ C  _Ph_a s e  _? 


SPA  90099001  A 
16  January  1987 

I_n t e r o£e r a b i_  1_ i  ty  Standa  rds  TM-Bus  Specification  .  The  primary 
purpose  of  the  TM-Bus  is  to  provide  a  common  means  for 
performing  test  and  maintenance  of  modules  at  the  circuit  level 
at  the  depot  or  factory.  It  is  also  intended  to  be  used  to 
support  on-equipment  maintenance  to  detect  and  isolate  faults 
to  a  module.  The  TM-Bus  may  be  used  operationally  to  perform 
fault  detection  and  isolation  on  those  modules  designed  to  use 
the  TM-Bus  in  that  manner.  It  shall  allow  the  module 
designated  as  a  maintenance  controller  (the  VHSIC  1  7 5 0 A  CPU 
module  shall  have  maintenance  controller  capability)  to 
initiate/command  self  test  functions  on  all  of  the  modules,  as 
well  as  support  the  collection  of  self  test  status  information 
and  make  that  status  available  external  to  the  functional  area. 

3.7.8  Sensor  Bata  Distribution  Network 


The  Sensor  Data  Distribution  Network  provides  the 
Signal  Processor  with  conditioned  sensor/preprocessor  input. 
The  SDDN  allows  any  sensor  to  directly  connect  to  any  Signal 
Processor  with  a  unidirectional  data  flow  of  500  MBPS  per 
channel.  The  SDDN  consists  of  fiber  optic  connections  from 


each  sensor  front-end  to  a  routing  network  and  then  to  each 
Signal  Processor.  The  routing  network  consists  of  matrix 
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connection  of  multiple  fiber  optic  channel  ports.  The  SDDN  has 


redundant  channels  and  is  reconfigured  only  upon  the 


occurrences  of  functional  Signal  Processing  Area  failures  or 


upon  major  mission  mode  changes. 


A  portion  of  the  SDDN,  the  Sensor  Control  Network, 
provides  the  communication  path  from  the  Signal  Processors  back 
to  the  Sensor  Subsystems.  Moding,  control  data  and  signal  data 
flow  from  Signal  Processors  to  a  routing  network  and  then  to 
sensor  front-ends  via  unidirectional  500  MBPS  fiber  optic 
channel  s . 


SPA  90099001  A 
16  January  1987 


3 . 7 . 8 . 1  Sys i  tem_ .Diagram 

A  diagram  of  the  network  is  shown  in  Figure 

3, 7. 8-1. 

3.7.9  Data  Exchange  Network 

The  Data  Exchange  Network  shall  permit  the  loading 
of  Signal  Processing  area  memories,  the  exchange  of  data  be¬ 
tween  Signal  Processors,  the  routing  of  encrypted  data  (black) 
from  TRANSEC/COMSEC  Secure  Data  Units  (SDUs)  to  the  Signal 
Processing  area  arid  the  routing  of  data  (red)  from  the  Signal 
Processing  area  to  the  TRANSEC/COMSEC  SDUs.  The  nata  Exchange 
Network  will  permit  a  unidirectional  flow  of  500  MBPS  per 
channel.  The  Data  Exchange  Network  shall  use  the  same  network 
approach  common  to  the  SDDN  and  the  VDDN. 

3 . 7 . 9 . 1  System  Diagram 

A  diagram  of  the  network  is  shown  in  Figure  3. 7. 9-1. 

3.7.10  Video  Data  Distribution  Network 

The  Video  Data  Distribution  Network  provides  the 
connectivity  between  all  video  data  sources  and  sinks.  Video 
sources  are  the  Signal  Processors  and  Stores  Management  System; 
video  data  sinks  are  the  cockpit  displays  and  mission  devices 
such  as  a  Video  Tape  Recorder.  The  VDDN  transfers  digital 
graphics  data  in  a  format  common  to  all  source  and  sink 
devices.  The  VDDN  routing  network  is  functionally  equivalent 
to  the  SDDN  and  DEN  using  common  fiber  optic  channels,  switch 
implementations,  and  interface  modules.  The  VDDN  shall  support 
six  simultaneously  active  display  channels.  A  minimum  of  four 
5 ? 5  line  resolution  and  two  875  line  resolution  color  pictures 
at  a  30  HZ  update  rate  shall  determine  the  minimum  composite 
transmission  rate  of  the  VDDN. 
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3.7.10.1  System  Diagram 

A  diagram  of  the  network  is  shown  in  Figure 

3.7.10-1. 

i 

3.7.11  System  Executive 

The  System  Executive  resides  in  the  Mission  Data 
Processors.  There  shall  be  two  copies,  one  of  which  is  desig¬ 
nated  the  primary  (System  Supervisor!,  and  the  other  is 
designated  the  standby.  The  standby  system  will  operate  in  a 
"hot  backup"  mode,  available  to  take  over  whenever  a  fault 
occurs  in  the  primary.  The  System  Executive  is  responsible  for 
monitoring  the  state  of  the  system  hardware  and  software.  The 
primary  means  of  system  status  monitoring,  communication,  and 
logging  will  be  a  system  data  base  which  is  located  in  each  of 
the  data  processors  and  is  maintainec  by  the  Distributed 
Executive.  Changes  of  device  and  task  status  will  be  broadcast 
over  the  high  speed  data  bus  as  an  update  to  the  local  copies 
of  the  state  tables  held  in  each  processor  and  in  the  System 
Mass  Memory.  The  System  Executive  is  responsible  for  keeping  a 
fault  log  for  al1  system  components  and  for  controlling 
reconfiguration  of  the  system  resources..  The  System  Executive 
handles  two  types  of  system  resource  reallocation.  First,  as 
functional  requirements  change  throughout  the  mission,  the 
system  components  must  be  reallocated  to  meet  these 
requirements.  These  requirements  represent  the  functional 
capabilities  which  were  defined  during  the  mission  planning 
process  and  modified  by  any  subsequent  inputs.  Second,  when 
any  system  component  currently  in  use  is  determined  to  have 
failed,  reallocation  of  the  remaining  components  may  be 
necessary  in  order  to  retain  any  functionality  lost  by  the 
failure.  If  the  mission  proceeds  as  planned,  the  pilot  will  be 
provided  with  the  expanded  functional  capabilities  and  the 
System  Executive  resource  allocation  process  will  be 
transparent.  Whenever  any  component  is  lost,  through  internal 
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failure  or  battle  damage,  the  System  Executive  will  provide  the 
pilot  with  a  report  of  any  planned  functional  capabilities  that 
will  be  unavailable  as  a  result  of  the  failure.  The  System 
Executive  functions/interfaces  are  depicted  in  figure  3,7.11-1. 

3,7.1?  Kernel  Executive 

The  Kernal  Executive  is  responsible  for  controlling 
the  application  software  assigned  to  a  processor,  providing 
control  and  communication  between  application  tasks,  control¬ 
ling  peripheral  devices,  and  participating  in  processor  level 
fault  tolerance  operations.  Control  of  the  application  soft¬ 
ware  is  provided  by  a  task  sequence  which  handles  the  invoca¬ 
tion  and  suspension  of  tasks  within  the  processor.  Interim 
task  control  and  commu  n  i  cat  ion  services  are  provided  to  support 
the  Ada  (MIL-STP-1R15A1  tasking  model  which  includes  the  con¬ 
cept  of  a  rendezvous  between  tasks,  allowing  intertask  control 
and  communication.  The  peripheral  device  control  capability  of 
the  Kernel  Executive  permits  an  application  task  to  request  an 
operation  on  a  peripheral  device  at  a  logical  level.  This 
function  is  provided  to  allow  the  application  software  execut¬ 
ing  in  the  data  processor  portion  of  the  signal  processors  the 
capability  of  controlling  the  execution  of  the  common  signal 
processing  modules.  Processor  level  fault  tolerance  operations 
include  the  receipt  of  processor  error  indicators,  analysis  of 
the  conditions,  and  determination  of  the  appropriate  action. 
This  appropriate  action  may  be  to  pass  the  condition  to  an 
application  task  for  further  action  by  an  exception  handler, 
notify  the  system  executive,  file  the  processor,  or  any  con¬ 
tinuation  of  these  or  other  actions. 


All  operating  system  services  required  by  the 
application  software  are  handled  through  the  Kernel  Executive 
which  in  turn  will  access  services  provided  by  the  Distributed 
Executive  as  reouired.  The  Kernel  Executive 
f unc t i ons / i n ter f a ces  are  depicted  in  Figure  3.7.1P-1. 
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3.7.13  Distributed  Executive 


The  Distributed  Executive  provides  bus  control 
interface  capability,  inter-processor  data  transfer  operations, 
and  general  participation  in  the  overall  system  operation.  The 
Distributed  Executive  communication  interface  provides  for  the 
exchange  of  information  between  processors.  Data  transfer 
requirements  will  result  from  transactional  requirements  in 
support  of  application  tasks  and  from  system  status  monitoring 
and  reconfiguration  operations.  System  software  and  hardware 
configuration  information  shall  be  maintained  by  every  pro¬ 
cessor  in  the  system.  The  Distributed  Executive  is  responsible 
for  the  maintenance  of  the  system  state  information  require¬ 
ments  and  system  operation.  The  Distributed  Executive  inter¬ 
faces  with  the  Distributed  Executive  in  other  processors  via 
the  Mission  Avionics  Multiplex  bus  and  with  the  Kernel  Execu¬ 
tive  resident  within  its  own  processor.  The  Distributed 
Executive  f uncti ons/ i nterfaces  are  depicted  in  Mgure  3.7.13-1. 


4,0  QUALITY  ASSURANCE  PROVISIONS  (Not  Applicable) 


5.0  PREPARATION  FOR  DELIVERY  (Not  Applicable) 
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6.0  NOTES 

6 . 1  Common  Module  Set 

The  maximum  use  of  common  line  replacable  modules 
across  the  entire  avionics  suite  is  a  basic  design  requirement 
for  the  Pave  Pillar  system.  Common  modules  are  used  to  perform 
common  functions  throughout,  the  system.  The  following 
subparagraphs  describe  a  representative  set  of  Common  Modules 
for  use  in  the  Pave  P  \  liar  archi  tecture  and  for  use  in 
associated  subsystems.  They  are  based  on  the  VHSIC  1750A  and 
Common  Signal  Processor  ADM  module  sets  under  development  as 
well  as  perceived  needs  for  additional  modules  not  currently 
under  development  under  those  programs.  Following  the  core  ADM 
set  of  modules,  (1-15)  additional  modules  are  specified  which 
are  not  constrained  by  the  implementation  approaches  currently 
being  used  on  the  V175DA  and  CSP  projects. 

In  the  signal  processing  area,  a  Module  Functional  Group 
is  identified  which  consists  of  one  controller  module  (Element 
Supervisor  Unit)  and  one,  two,  or  more  functional  element 
modules  (Global  Memories,  Processing  Elements,  or  I/D  modules) 
that  are  locally  controlled  by  that  Element  Supervisor  Unit 
(ESU).  This  Module  Group  can  also  be  viewed  as  a  type  of 
Supermodule  with  three  standard  interfaces:  the  PI-Rus,  the 
TM-Pus,  and  the  Data  Flow  Network  interface.  With  VHSTC  Phase 
1  circuitry  it  usually  is  not  possible  to  contain  a  complete 
signal  processing  module  group  on  a  single  module;  hence 
several  modules  are  necessary  for  CSP  functions.  This 
necessitates  local  interfaces  between  modules  which  need  to  be 
standardized  for  a  given  family  of  modules.  Within  CSP  two 
local  buses  are  specified,  the  Element  Control  Rus  (ECB)  and 
the  Element  Maintenance  Bus  (EMR)  which  currently  are  unique  to 
the  CSP  set  of  modules.  In  the  future,  it  is  expected  that 
these  local  buses  will  be  absorbed  into  the  module. 
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Three  power  modules  are  included  which  provide  the  Pave 
Pillar  architecture  with  a  set  of  modules  capable  of  powering  a 
variety  of  system  configurations.  The  power  modules  conform  to 
the  SEM  E  form  factor.  The  OC-DC  convertor  modules  are 
distributed  throughout  the  system  backplane,  which  improves  the 
power  system's  transient  response.  The  modules  are  connected 
in  parallel  and  share  the  load  equally,  allowing  the  addition 
of  the  appropriate  number  of  spares  to  the  system. 
Built-in-Test  features  report  module  faults  to  the  system, 
warning  the  user  to  avoid  critical  modes  and  reducing  the 
maintenance  support.  The  power  system  shall  include  Nuclear 
Event  Detection  (NED)  and  Electromagnetic  Pulse  ( EMP ) 
circumvention.  The  power  system  shall  have  an  overall  power 
density  of  A  watts/cubic  inch,  an  efficiency  of  70%  to  80%,  and 
a  weight  efficiency  of  0.0?  pounds/watt.  The  following  sub- 
paragraphs  describe  a  set  of  common  modules  for  use  in  the  Pave 
Pillar  Architecture.  Table  6.1-1  lists  the  module  types  which 
form  this  baseline  set. 

6.1.1  VHSIC  1750A  Processor  Module  (V1750A) 

The  1 7  50 A  Processor  Module  will  consist  of  a  1750A 
Instruction  Set  Architecture  (ISA)  CPU  with  256K  words  of 
dedicated  local  memory  and  shall  contain  two  Pi-Bus  interfaces, 
a  Test  and  Maintenance  Bus  interface  and  an  IEEE  488  Bus 
interface.  The  1  7  5 0 A  Processor  Module  shall  be  capable  of  a 
minimum  of  3  Million  Instructions  Per  Second  (MIPS)  assuming  a 
DAIS  MIL-STD-1750A  weighted  instruction  mix  without  extended 
memory  addressing  capability  enabled  and  a  minimum  of  ?  MIPS 
with  extended  memory  addressing  enabled.  The  1750 A  Processor 
Module  shall  contain  internally  (in  non-volatile  memory)  a  4K 
word  start-up  ROM  for  storing  initialization  and/or  Kernel 
Executive  software.  The  Non-Volatile  1750 A  Processor  Module 
shall  be  functionally  identical,  except,  that  its  program 
storage  memory  (ROM)  shall  not  be  alterable  in  flight.  In 
addition,  since  the  module  shall  not  perform  self  loading,  the 
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TABLE  6.1-1 

BASFLINE  COMMON  MODULE  SET 

VHSIC  1 7 50 A  CPU  Module  {V1750A1 
Avionics  Bus  Interface  Module  IABI1  Module 
Bulk  Memory  Module  ( BMM )/ Non-vol a t i 1 e  Bulk 
Memory  Module  ( NVBMM ) 

MIL-STR-1553B  I/O  Module  (V1553B1 
Dedicated  Interface  Modules 

-  A/D  Conversion 

-  D/A  Conversion 

-  Pi scretes  In 

-  Discretes  Out 

-  Serial  Channel  Hn  &  Out  1 
Floating  Point  Processing  Element  (FPPFl  Module 
Global  Memory  iGMl  Module 

Data  Network  Element  iDNEl  Module 
Sensor  Interface  (Sll  Module 
Element  Supervisor  Unit  (ESU)  Module 
Timing  and  Control  Generator  (TCG)  Module 
I/O  Terminator  Module 
DC-DC  +5  Volt  Power  Converter  Module 
DC-DC  Mu  1 ti -vol tage  Power  Converter  Module 
Power  Conditioner  Module 

Fixed  Point  Vector  Processing  Element  (VPE1 
Modu  1  e 

Electronic  Warfare-oriented  Processing  Element 
Modules 

Biphase  Correlator  Processing  Element  fRCPE) 

Module 

MIL -STD-1760  Stores  I/O  Module 
Video  Module 
Display  Module 
Network  Switch  Module  (NSM) 

Key  Generator  Module  1KGH) 
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internal  Kernel  Executive  software  shall  be  unique.  The  1750A 
Processor  Module  is  shown  in  Fiqure  6. 1.1-1. 

6.1.?  Avionics  Bus  Interface  fABII  Module 

The  Avionics  Bus  Interface  (ABI)  Module  shall  be  desiqned 
to  interface  with  either  the  Mission  Avionics  Multiplex  Bus, 
the  Block  Transfer  Multiplex  Bus,  or  the  Vehicle  Management 
System  Multiplex  Bus.  The  A B I  shall  contain  two  Pi-Bus 
interfaces  and  a  test  and  Maintenance  Bus  interface.  The  A R I 
shall  provide  for  redundant  media  and  shall  provide  redundant 
data  paths  within  the  module.  The  ARI  Module  is  shown  in 
Figure  6. 1.2-1. 

6.1.3  Bulk  Memory  Module  ( BMM )  /  No  n^Vo  1  a  t  i  1  e  _P»_u  Ik  Memory 
ModuU^NVBMM^ 

The  Bulk  Memory  Module  shall  be  capable  of  storing  ? 
million  words  of  Random  Access  Memory.  There  shall  be  two 
versions  of  this  Module.  One  version  shall  contain  volatile 
memory  and  the  other  version  shall  contain  Non-Volatile  Memory. 
The  Module  shall  contain  two  PI-Rus  interfaces  and  a  Test  and 
Maintenance  Bus  interface.  The  Bulk  Memory  Module  shall 
utilize  a  single  error  correction/double  error  detection 
scheme.  The  Bulk  Memory  Module  is  shown  in  Figure  6. 1.3-1. 

6 . 1 . 4  MI L-STP-1553B  I/O  Module 

The  MIL-STD-1553B  I/O  Module  shall  Drovide  a  dual 
redundant  MJL-STD-1553B  Multiplex  Bus  interface  terminal.  The 
bus  terminal  shall  be  programmable  to  operate  in  either  Master 
or  Pemote  mode.  The  module  will  have  two  Pi-Bus  interfaces  and 
a  test  and  Maintenance  Bus  interface.  The  MIL-ST0-15B3B  I/O 
Module  is  shown  in  Figure  6. 1.4-1. 
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6.1.5  Dedicated  Interface  Module 


The  Dedicated  Interface  Module  shall  provide  the  buffering 
and  control  circuitry  to  manage  discrete  interface  signals, 
both  input  and  output,  such  as  analog  to  digital,  digital  to 
analog,  synchro,  serial  cnannels,  TTL  level,  etc.  The 
Dedicated  Interface  Module  may  be  designed  as  several  mixes  of 
signal  types  per  module.  The  Dedicated  Interface  Module  will 
have  two  Pi-Bus  interfaces  and  a  test  and  Maintenance  Rus 
interface.  The  Dedicated  Interface  Module  is  shown  in  Fiqure 
6. 1.5-1. 
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6.1.6  a  t  j^£_Po  i_n  t_P  ro  ces  sji_nci  £l£E!£££ _!££££!  Modulo 

The  Floating  Point  Processing  Element  iFPPEl  shall  provide 
the  capabilities  to  process  both  3?-hit  floating  point  and  16- 
and  3?-b i t  fixed  point  arithmetic  efficiently  for  sional 
processing  computations.  This  module  shall  be  able  to  perform 
IPS  million  floating  point  operations  per  second  or  1P.5 
million  complex  floating  point  operations  per  second.  The 
module  shall  support  floating  and  fixed  point  multiplication, 
addition,  subtraction,  comparisons,  data  dependent  operations 
and  data  conversions.  It  shall  also  support  logical 
operations,  table  look-up  functions,  square  root  and  reciprocal 
calculations,  sine/cosine  generation,  arctangent  generation, 
optionally  selected  data  clamping,  optionally  selected  status 
reporting,  and  error  reporting.  The  FPPE  shall  permit 
overlapped  task  execution  with  task  loading  and  unloading.  It 
shall  include  local  memories  for  data  and  coefficient  storage 
ot  at  least  16 K  3? -bit  data  words  visible  during  task 
execution.  The  FPPE  shall  include  the  capability  to  check  for 
a  variety  of  internal  errors,  including  parity  errors, 
addressing  errors,  arid  calculation  errors.  Detected  errors 
shall  be  logged  in  a  non-volatile  fault  log  memory  device  for 
later  access  over  the  Element  Maintenance  Bus  fEMRl. 

The  FPPE  shall  have  3  external  interfaces: 

a.  Element  Control  Bus  (ECBl,  ICD  P8758P6 

b.  Element  Maintenance  Bus  (EMBl,  ICD  P8757R5 

c.  Data  Flow  Network  (DFN)  Interface,  IC!)  ?  8  7  5  7  B  8 

The  ECB  is  a  local  control  bus  from  the  Element  Supervisor 
Unit  ( E S U )  which  controls  the  FPPE;  it  selects  w h i c h  signal 
processing  Macros  to  execute,  establishes  data  network  paths 
and  messages,  etc.  The  EMR  is  a  local  maintenance  bus  for 
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testing  and  fault  isolating  the  FPPF  from  the  ESC.  The  DFN 
port  provides  high  speed  access  to  sensor  data  stored  elsewhere 
in  the  system,  such  as  in  Global  Memoriesv  or  arriving  over 
Sensor  Interfaces  (SIsK  The  FPPE  Module  is  shown  in  Figure 
6. 1.6-1. 
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6.1.7  emo  d u  T_e 

The  Global  Memory  Module  shall  be  capable  of  storing  1 
million  32-bit  data  words  of  volatile  memory.  The  module  shall 
support  complex  address  modes  needed  for  signal  processing, 
including  the  following: 

a.  Circular  Queue  and  Multiple  Circular  Queues 

b.  Corner  Turn  Queues 

c.  Coordinate  Potation  Queues 

d.  Random  Access  Queue 

e.  Buffer 

These  address  modes  shall  be  supported  at  a  burst  transfer 
rate  of  25  million  32-bit  words  per  second.  The  memory  shall 
support  logical  to  physical  address  translation  in  order  to 
prevent  memory  fragmentation.  The  mapping  scheme  shall  use  4K 
block  sizes  and  permit  a  logical  space  larger  than  physical 
memory  to  aid  in  memory  management. 

The  CM  shall  include  error  detection  and  correction 
circuitry  on  the  main  memory.  The  implementation  shall  be  8 
FDC  bits  that  correct  in  4-bit  groups  (4-bit  wide  memory 
circuits  are  specified,  hence  error  patterns  of  4  bits  are 
likely).  The  GM  shall  include  a  non-volatile  fault  log  memory 
device  for  recording  detected  faults  for  later  maintenance. 

The  GM  shall  have  3  external  interfaces: 

a.  Element  Control  Bus  ( FCB)  ,  I  CD  2875826 

b.  Element  Maintenance  Pus  (EMB),  1CD  2375785 
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c.  Data  Flow  Network  (DFN)  Interface,  ICO  2875788 

The  ECB  is  a  local  control  bus  from  the  Element  Supervisor 
Unit  (ESU)  which  permits  the  ESU  to  control  the  GM  and  provides 
a  path  for  the  GM  to  access  ESU  main  memory  and  the  PI-Rus 
interface.  The  ECB  shall  permit  transfers  from  ESU  elements  to 
Global  Memory,  GM  address  translation  memory,  and  the  Data  Flow 
Network.  The  EMB  is  a  local  maintenance  bus  for  testing  and 
fault  isolating  the  GM  from  the  ESU.  The  DEN  port  provides 
high  speed  access  to  data  stored  in  the  GM  to  other  elements  in 
the  signal  processing  function,  such  as  FPPEs  and  Sis.  The 
Global  Memory  Module  is  shown  in  Figure  6. 1.7-1. 
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6,1.8  Da  ta_  Network  Element  (ONE)  Module 

The  ONE  Module  shall  permit  the  implementation  of  a 
variety  of  configurations  of  Data  Flow  Networks  with  respect  to 
the  number  of  ports  and  the  width  of  the  data  words 
transferred.  The  baseline  Data  Flow  Network  for  the  signal 
processing  function  has  24  ports  using  32-bit  data  word 
transfers;  it  permits  12  simultaneous  paths  to  be  operating 
between  the  24  ports.  This  configuration  requires  8  DNE 
Modules.  The  DNE  Module  shall  have  12  ports  each  with  16  data 
lines.  The  DNE  shall  be  able  to  transfer  between  up  to  6  sets 
of  external  Master/Slave  pairs  of  elements  connected  to  the 
module  simultaneously.  The  ports  shall  operate  in  half  duplex 
mode:  data  car.  transfer  in  either  direction,  but  only  one 

direction  at  a  time.  Once  a  path  is  established,  transfers 
shall  take  place  at  a  25  million  word  rate.  The  operation  of 
the  path  shall  conform  to  the  interface  design  specification 
for  the  Data  Network.,  1CD  2875788.  The  DNE  shall  provide  error 
checking  for  transfers  over  the  Data  Flow  Network.  Odd  parity 
shall  be  provided  on  each  16-bit  data  segment,  A  non-volatile 
fault  log  memory  circuit  shall  be  included  on  the  DNF.  to  log 
any  DNE  faults. 


Tho  DNE  Module  shall  have  two  external  interfaces 


a.  The  Data  Flow  Network  ports  as  documented  by 
I  CD  2876788. 

b.  The  Element  Maintenance  Bus  (EMB)  as  documented 
by  I  CD  2875785  . 

The  EMB  shall  permit  an  ESU  to  access  the  fault  log  memory 
device  and  determine  the  health  of  the  DNE  Module,  The  DNE 
Module  is  shown  in  Figure  6, 1.8-1. 
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6.1.9  Sensor  Interface  f  SI  1  Modu  1  e 

The  SI  Module  provides  a  gateway  between  internal  signal 
processing  group  data  paths  and  an  external  sensor  data 
distribution  network.  The  principal  gateway  is  between  the 
Data  Flow  Network  dud  trie  external  sensor  channel;  paths  also 
exist  between  the  Element  Supervisor  Unit  MiSUl  local  memory 
and  the  sensor  channel  and  the  FSU  local  memory  and  the  Data 
Flow  Network.  The  ESU  connects  to  the  Pi-Bus  and  TM-Bus,  thus 
permitting  transfer  between  those  buses  and  the  other  paths. 

The  external  interfaces  to  the  SI  Module  are: 

a.  Element  Control  Bus  (ECB)  documented  by  ICO 
?8758?6 

b.  Element  Maintenance  Hus  1EMB)  documented  b.v  ICO 
?  8  7  5  7  8  5 
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c.  Data  Flow  Network  (DFN)  documented  by  ICO 
2875788 

d.  Sensor  Data  Distribution  Network  (SDDN). 

The  ECB  permits  the  ESU  controller  module  to  manage  the  SI 
module.  The  ESU  initializes  the  SI,  fields  interrupts  and 
reads  status,  and  permits  SI  access  to  message  control  blocks 
via  DMA  transfers  from  the  ESU  local  memory.  The  ECB  path 
permits  Pi-Bus  to  SI  transfers  which  in  turn  may  be  forwarded 
over  the  Data  Flow  Network  or  the  external  Sensor  Data 
Distribution  Network. 

The  EMB  permits  the  ESU  to  initiate  SI  self-test  and  read 
the  resulting  status.  It  permits  access  to  a  non-volatile 
fault  log  memory  on  the  SI  storing  any  detected  faults. 

The  Data  Flow  Network  port  on  the  S!  is  the  principal  data 
transfer  path  to  the  SI  from  the  signal  processor  modules.  It. 
is  used  for  sensor  data  transfers  from  sensor  front-end  units 
to  Global  Memories  or  processing  elements.  It  can  also 
transfer  data  from  signal  processing  modules  to  front-end 
units. 

The  SI  port  to  the  external  sensor  data  distribution 
network  permits  sensor  data  to  be  input  to  the  si  anal 
processing  modules.  It  shall  have  a  burst  transfer  rate  of  500 
million  bits  per  second.  It  shall  support  a  point-to-point 
transfer  configuration.  The  baseline  physical  link  layer  shall 
be  implemented  with  fiber  optics  (alternate  media  may  be 
appropriate  for  near-term  application  such  as  wire  provided  the 
performance  requirements  art  met).  The  design  shall  also 
support  other  configurations  such  as  a  ring  bus.  Error 
detection  shall  be  provided  on  the  sensor  data  distribution 
channel  . 
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The  SI  module  shall  support  overlapped  transfers  from  the 
front-end  units  and  the  signal  processing  Data  Flow  Network  so 
that  continuous  data  streams  may  he  accommodated.  Local 
buffering  on  the  module  shall  consist  of  at  least  three  4K  x  34 
data  huffers  to  support  overlapped  operations.  The  SI  Module 
is  shown  in  Figure  6. 1.9-1. 
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6.1.10  Element  Supervisor  Unit  (ESU)  Module 

The  ESU  Module  is  the  controller  module  for  signal 
processor  processing  element  (PE)  modules.  Global  Memory  (GMl 
modules,  and  interface  modules.  It  shall  perform  the  control 
function  for  the  Floating  Point  Processing  Element  (FPPE),  the 
fixed  point  Vector  Processing  Element  (VPE),  the  Riphase 
Correlator  Processing  Element  (BCPE),  the  low  latency  General 
Purpose  Processing  Element  (GPPE),  the  GMs,  the  Sensor 
Intefaces  (Sis),  and  the  COMSEC  interface  (Cl).  It  performs 
the  maintenance  function  for  the  Data  Network  Element  (DNE). 

The  ESU  shall  have  the  following  external  interfaces: 

a .  Pi-Bus . 

b.  TM-Bus. 

c.  Element  control  Bus  (ECB). 

d.  Element  Maintenance  Bus  (EMB). 

The  Pi-Bus  (See  Appendix  B  -  VHS I C _ Phase _ ? 

_ -  PI  -  Bus )  >  provides  a  path  for  the 

signal  processing  module  "group"  controlled  by  the  ESU  to 
communicate  with  the  rest  of  the  signal  and  data  processing 
system.  It  is  used  primarily  for  control  messages.  The  Pi-Bus 
interface  on  the  ESU  shall  provide  autonomous  DMA  capability  to 
local  ESU  memory. 

The  TM-Bus  (See  Appendix  C  -  VHSJ_C _ Phase _ ? 

I nteroperabi 1 i ty  Standard  -  TM-Bus),  provides  a  path  for  test 
and  maintenance  commands  and  data  to  be  sent  to  the  ESU  and  the 
modules  it  controls. 

The  ESU  shall  implement  a  hierarchical  maintenance  bus 
system  with  the  Element  Maintenance  Bus  (EMB),  documented  in 
ICD  ?  8  7  5  7  8  5  ,  connecting  the  ESU  to  the  modules  it  controls. 
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6.1.11  Iigll!19_j.Ild_Cori tro  1  Ggnerator  M'CG)  Module 

The  ICO  module  shall  provide  the  system  clocks  needed  by 
signal  and  data  processing  core  modules.  It  shall  also  contain 
a  system  fault  log  non-volatile  memory  for  recording  faults  for 
modules  or  components  not  having  fault  log  memories.  It 
accepts  a  Power  On  Reset  signal  from  the  power  supply  system, 
software,  or  an  external  source  and  generates  a  system  reset 
signal.  The  clocks  provided  by  the  TCG  shall  include: 

a.  25  MHz  for  basic  VHSJC  Phase  1  circuitry  use, 

b.  12.5  MHz  for  Pi-Bus  clocking. 

c.  6.25  MHz  for  TM-Bus  clocking. 

Because  of  skewing  problems,  individual  signals  for  each 
module  shall  be  generated  for  distribution.  The  TCG  Module  is 
shown  in  Figure  6.1.11-1. 


Hflur*  •.1.11-1  TIMING  AND  CONTROL  GENERATOR  (TCG)  MODULE 
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6,1.12  I/O  Terminator  Module 

The  I/O  Terminator  Module  shall  provide  I/O 
for  the  Pi-Bus,  the  TM-Bus,  and  any  other  system 
termination.  The  I/O  Terminator  Module  is  shown 
6.1.12-1. 
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6.1.13  DC-DC  5_Vo 1 t_Power_Con ve r te r^Modu^P 

The  5  volt  power  converter  module  shall  be  capable  of 
supplying  200  watts  with  +/-5%  regulation.  It  shall  use  +  /- 24 
VOC  as  input.  It  shall  occupy  a  single  0.6  inch  module  slot  on 
the  backplane.  It  shall  include  sense  circuits  for  detectinq 
if  the  module  is  supplying  power,  if  the  voltage  is  within 
regulation,  and  if  the  module's  temperature  is  within  its 
thermal  limit.  The  sense  outputs  shall  be  available  at  a  BIT 
interface,  baselined  as  discretes  signals.  ^  The  Power 
Conditioner  module  is  specified  to  be  a  central  collection 
point  for  BIT  discretes  for  the  distributed  converter  modules. 1 
The  module  5  volt  output  is  through  the  module  connector  to  the 
backplane  which  distributes  the  voltage  to  user  modules. 

Fuse  links  shall  disconnect  a  module  from  the  system  in 
the  event  a  module's  output  shorts.  Overvoltage  protection 
will  prevent  damage  to  other  modules.  The  DC-DC  5  Volt  Power 
Convertor  Module  is  shown  in  Figure  6.1,13-1. 


Figure  6.1.13-1  DC-DC  ♦  #  V  POWER  CONVERTER  MODULE 
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6.1.14  ^£"2C_Mult j_^Volta.2e_Powe r_Co n ver ter  Module 

The  mul ti -vol tage  converter  module  shall  provide  +/-15, 
+3.3,  and  +  2  volts.  It  shall  require  a  +/-? 4  volt  input.  It 
shall  occupy  a  single  0.6  inch  slot.  It  shall  include  sense 
circuits  for  detecting  if  the  module  is  supplying  power,  if  the 
voltage  is  within  regulation,  and  if  the  module's  temperature 
is  within  its  thermal  limit.  The  sense  outputs  shall  be 
available  at  a  BIT  interface,  baselined  as  discretes  signals. 
(The  Power  Conditioner  module  is  specified  to  be  a  central 
collection  point  for  BIT  discretes  for  the  distributed 
converter  nodules.)  The  module  outputs  are  brought  out  through 
the  module  connector  to  the  backplane  which  distributes  them  to 
user  modules.  Potential  future  requirements  of  +/-12,  -?.0, 
arid  •»  5 .  ?  volts  have  been  identified  for  the  High  Speed  Pata  Bus 
(H5DB)  interface.  The  mul ti -vol tage  module  shall  be  adaptable 
to  be  able  to  provide  these  voltages  with  modest  current 
capabilities.  Fuse  links  shall  disconnect  a  module  from  the 
system  in  the  event  a  module's  output  shorts.  Overvoltage 
protection  will  prevent  damage  to  other  modules.  The  DC-DC 
Mul ti -Vol tage  Power  Converter  Module  is  shown  in  Figure 
6,1.14-1. 
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6.1.15  Power  Conditioner  Module 


The  Power  Conditioner  Module  filters  the  aircraft  power 
bus  and  converts  it  to  +/-24  VDC  for  distribution  to  the  DC-DC 
converter  modules.  It  shall  be  able  to  accept  input  power  from 
either  a  115  VAC  400  Hz  3-phase  A  wire  Wye  power  source  or  a 
?70  VOC  power  source.  Sense  circuits  shall  be  included  to 
detect  if  the  module  is  outputting  power,  if  the  output  is 
within  + / - 1 o %  regulation,  and  if  the  module's  temperature  is 
within  its  thermal  limit.  These  BIT  discrete  signals  shall  be 
available  to  the  system  over  a  TM-Rus  interface.  In  addition, 
the  Power  Conditioner  shall  log  any  detected  faults  in  a 
non-volatile  memory  device  within  the  Power  Conditioner  for 
later  maintenance  use.  The  baseline  design  includes  the 
ability  to  accept  PIT  discrete  inputs  from  the  distributed 
nC-PC  converters  for  output  over  the  TM-Bus  to  the  system  and 


logging  within  the  Power  Conditioner. 
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disconnect  the  module  from  the  system  in  the  event  its  output 
shorts.  Overvoltage  protection  shall  be  provided  to  prevent 
damage  to  other  modules.  The  Power  Conditioner  shall  maintain 
enough  stored  energy  to  provide  power  through  a  50  microsecond 
prime  power  loss.  Distribution  of  the  +/-?4  VDC  is  through 
separate  parallel  conductors  connecting  to  the  distributed 
converter  modules  independent  of  the  backplane.  The  Power 
Module  is  shown  in  Figure  6,1,15-1. 
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Figure  6.1.15-1  POWER  CONDITIONER  MODULE 
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6,1.16  £iHl  V £ c t o r _ P r o c e n £_ Fl_ e m e n t V P £ 1 

Module 

The  VPE  module  is  a  16-bit  fixed  point  arithmetic 
vector-oriented  processing  element  that  operates  efficiently  on 
complex  (1  and  Ql  data  arranged  in  vectors  or  matrices.  Its 
arithmetic  support  is  augmented  for  complex  multiplys,  adds, 
and  subtracts  to  provide  for  very  fast  FFT  calculations, 
convolutions,  correlations,  etc.  It  is  intended  to  perform 
computationally  intensive  radar  signal  processing  functions 
such  as  pulse  compression  and  adaptive  sidelobe  cancellation 
perhaps  three  times  as  fast  as  a  FPPF.  (One  VPE  could  replace 
3  FPPEs  in  a  radar  application  for  Trac k -Wh i 1 e- Sea n  modes,  for 
instance. 1  The  VPE  shall  include  fault  detection  and  isolation 
logic,  including  parity  check  circuits,  arithmetic  error 
checking,  etc,  and  include  a  non-volatile  fault  loa  memory 
device.  The  VPE  shall  meet  the  standard  signal  processing  PE 
interfaces: 

a.  Element  Control  Rus  (ECB) 

b.  Flement  Maintenance  Bus  (EMB) 

c.  Data  Flow  Network  (DFN). 
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Figure  6.1.16-1  FIXED  POINT  VECTOR  PROCESSING  ELEMENT  MODULE 
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6.1.17  Electronic  Warfare-oriented  Processing 
_Ej_e  ni  e__n  jt  o  u  1  es 

The  Electronic  Warfare  functional  area  requires  diqital 
sorting  and  filtering  functions  with  very  high  throughput 
requirements  at  the  "front-end"  of  the  EW  processing  load.  The 
detailed  requirements  of  this  Sort  Enhanced  Processing  Element 
ISEPE1  module  are  TRD.  A  low  latency,  General-Purpose 
Processing  Element  (GPPE)  is  also  needed  in  the  EW  area.  This 
module  shall  implement  a  3?-bi t  Reduced  Instruction  Set 
Architecture  (RISAl  with  a  target  throughput  goal  of  10  million 
instructions  per  second.  It  shall  have  a  very  fast.  I/O 
instruction  capability  to  meet  short  response  I/O  requirements; 
a  ?-c1ock  I/O  instruction  capability  is  a  goal.  It  shall 

directly  address  large  memory  sizes.  It  shall  interface  to  the 
Data  Flow  Network,  the  PI -Bus ,  and  the  TM-Bus.  It  shall 

include  a  Fault  Log  memory  device  for  maintenance  purposes. 
The  FW  Processing  Element  Module  is  shown  in  Figure  6,1.17-1. 
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6.1.18  Biphase  Correlator  Processing  Element 
( BC P F. )  Module 

The  Biphase  Correlator  Processing  Element  (BCPE)  shall  be 
designed  to  efficiently  compute  biphase  correlations  of  signals 
with  2  to  16  bits  of  accuracy  and  16  to  512  points.  The  8CPE 
throughput  shall  be  adequate  to  pei form  the  CNI  broadband 
acquisition  correlation  functions  for  JTIDS,  GPS,  etc,  and  the 
radar  (URR1  pulse  compression  functions  when  biphase  methods 
are  used.  The  BCPE  shall  contain  a  minimum  of  two  8K  banks  of 
local  memory  that  permit  overlapped  I/O  and  computation.  The 
BCPE  shall  have  3  external  interfaces: 

a.  Element  Control  Bus  (ECB) 

b.  Element  Maintenance  Bus  f EM B > 

c .  0  a  t  a  Flow  Network  ' 0  F  N ) 

(See  paragraph  6.1.6  FPPE  Module  for  a  description  of  these 
three  interfaces.) 

The  BCPE  shall  include  fault  detection  and  isolation 
capabilities  for  internal  memories,  buses,  and  arithmetic 
elements.  Tt  shall  include  a  non-volatile  fault  log  memory. 
The  BCPE  Module  is  shown  in  Figure  6.1.18-1. 

6.1.19  MIL-STp-1760  Stores  I/O  Module 

The  MIL- STD- 1760  Stores  I/O  Module  shall  provide  all  the 
MIL-STD-1760  I/O  interfaces  to  a  stores  station  (video,  audio, 
analog,  discretes,  and  power  1.  The  module  will  have  a  Pi-Bus 
inter face.  Test  and  Maintenance  Bus  interface,  and  two  Video 
Data  Distribution  Network  interfaces.  The  MIL-STD-1760  Stores 
I/O  Module  is  shown  in  Figure  6.1.19-1. 


-  86 


SPA  90099001  A 
16  January  1 9  P  7 


•  PHASE 
CORRELATOR 
PROCESSING 
CLEMENT  MODULE 


CC-BUS 

1  1 

INTEGRATED 
>  RACK 
BACKPLANE 

CM-BUS 

DATA  FLOW  NETWORK  j 

Figure  6.1.18-1  BIPHASE  CORRELATOR  PROCESSING  ELEMENT  MODULE 


VIDEO 

DATA 

DISTRIBUTION 

NETWORK 


PI-BUS  #1 


PI-BUS  «2 


TM-iUS 


EXTERNAL 


C“ 


AUDIO 

MIL-STD-I 760 

ANALOG 

STORES  I/O  MODULE 

DISCRETES 

POWER 

ONE 
>  1  760 
INTERFACE 


INTEGRATED 

RACK 

Backplane 


Figure  6.1.19-1  MIL-STD-17B0  STORES  I/O  MODULE 


.  y”-  <%  •:  - 


-  87  - 

.  '  /. Lf  ^  JL.1  it \  Jtr.  .-■!  aJj  ■jjv  tiJ  /■-*  ■ 


SPA  90099001  A 
16  January  1987 


6 . 1 .  2  0  Video  Module 

The  Video  Module  shall  be  capable  of  extracting 
information  from  data  memory  and  creating  pictures  for  display. 
The  module  shall  do  character  generation  and  shall  be  capable 
of  outputting  high  resolution  color  video  for  display  in  the 
cockpit.  The  video  module  shall  also  be  capable  of  accepting 
and  processing  video  data  received  from  the  stores  stations  and 
providing  this  data  to  the  video  displays.  The  video  memory 
module  shall  provide  the  ability  to  store  many  types  of  video 
data  (monochrome,  color,  etc)  based  on  multiples  of  the  minimum 
number  of  TV  lines.  A  512  x  512  x  16  module  for  example  could 
be  configurable  to  permit: 

-512  x  512  x  12  (four  bit  planes  for  each  primary  color) 
-1024  x  512  x  4  (monochrome) 

-1024  x  1024  x  4  (monochrome) 

-Simultanous  buffering  for  rada r/ EO/ I RST 
-Backup  for  failed  memory  modules 

The  video  module  is  a  functional  element  in  the  Common 
Signal  Processor  and  contains  Element  Control  Bus,  Element 
Maintenance  Bus,  and  Data  Flow  Network  interfaces.  The  Video 
Module  is  shown  in  Figure  6.1.20-1. 

6.1.21  Display  Module 

The  Display  Module  is  the  final  destination  of  Video  Data 
from  the  Video  Distribution  Network  arid  is  resident  with  the 
display  device.  It  interfaces  directly  to  the  display 
electronics  through  the  Data  Flow  Network.  The  Video  Module 
also  interfaces  to  the  PI  Bus  for  control  and  the  Test  and 
Maintenance  Bus.  The  Display  Module  is  shown  in  Fig.  6.1.21-1, 
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6.1.22  Network  Switch  Module 

The  Network  Switch  Module  is  shown  in  Figure  6.1.22-1.  It 
is  used  as  shown  in  Figure  6.1.22-2  to  provide  the  interconnect 
routing  for  the  SDDN,  DEN  and  VDDN.  The  NSM  shall  be  capable 
of  connecting  any  of  the  500  MBPS  fiber  optic  input  channels  to 
any  of  the  500  MBPS  output  channels  under  command  of  a  local 
V1750A  control  processor  via  dual  redundant  Pi-Bus  interfaces. 
The  prime  data  path  is  between  NSM  input  channels  and  NSM 
output  channels.  Reouests  to  configure  the  input  to  output 
connectivity  are  received  on  the  Mission  Avionics  Multiplex  Bus 
and  passed  to  the  control  processor  via  the  local  Pi-Bus. 
Switch  test,  status  and  reconfiguration  commands  are  sent  to 
the  switch  from  the  local  controller  via  the  local  PJ-Bus. 
Switch  status  is  returned  to  the  local  controller  via  the  local 
PI  -Bus  . 

The  NSM  shall  support  non-blocking  n  X  n  interconnect 
between  input  and  output  channels  at  the  maximum  network  data 
rate  (500  MBPS  per  channel).  The  number  of  channels  per  NSM, 
the  allocation  of  channels  among  sources  and  sinks,  and  the 
number  of  NSMs  per  network  are  system  design  dependent 
parameters . 


Figure  6.1.22-1  NETWORK  SWITCH  MODULE 
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6.1.23  Key .Genera tor  Module  (KGM) 

The  Key  Generator  Module  ( KGM  1  shall  be  a  qeneral  purpose 
cryptographic  module  capable  of  encryption  and  decryption  of 
all  digital  data  and  messages  including  IFF  and  voice  signals. 
It  shall  provide  COMSEC  protection  of  digital  data  at  all 
classification  levels.  The  KGM  shall  also  accept  manual  key 
load,  fault  alarm,  tamper  detect,  and  internal  zeroize 
functions.  It  shall  perform  multi-mode  operation  at  a  data 
rate  of  20  Mbps,  with  a  maximum  latency  of  100  microseconds. 
The  KGM  shall  have  a  crypto  ignition  key  interface  to  allow  the 
pilot  to  enter  key  code  inputs  for  access  to  secure  data.  The 
KGM  module  is  shown  in  Figure  6.1.23-1. 
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6  *  ?  Pa  c ka^i_n£ 

The  objective  of  avionics  packaging  is  to  develop  a 
standardized  set  to  allow  interchangeability  of  equipment 
within  an  aircraft  and  also  between  different  aircraft  types 
which  contain  similar  functional  units.  The  packaging  concept 
will  provide: 

o  A  set  of  line  replaceable  modules  (LRMl 
o  A  set  of  standardized  avionics  enclo¬ 
sures/racks. 

The  key  design  objectives  and  constraints  include 
the  following: 

o  Direct  access  to  the  LRMs 

o  Minimizing  installed  avionics  weight  and  volume 

o  Mechanical  simplicity 

o  Guards  against  inadvertent  installation  of  an 
LRM  into  the  wrong  slot 

o  Effective  thermal  control  of  the  equipment 
o  Improvements  in  reliability  and  maintainability 
o  Improved  testability  to  allow  fault  isolation 
to  LRM  level 

o  Improved  tolerance  to  battle  damage 

o  Elimination  of  single  point  failure  modes. 

6.2.1  Equipment  Enclosure 

The  equipment  enclosures  shall  be  modularized  with 
standard  dimensions  to  allow  use  of  building  block  subassem¬ 
blies.  An  integrated  rack  design  compatible  with  two -level 
maintenance  procedures  shall  be  used. 

Liquid  cooling  shall  he  the  primary  mechanism  of 
heat  dissipation  for  the  equipment  cooling  system.  The 
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enclosure  interface  with  the  equipment  cooling  system  shall  be 
specified  in  terms  of  heat  dissipation  requirements.  Loss  or 
reduction  of  cooling  capacity  shall  not  cause  degradation  in 
avionics  performance  below  specified  limits  or  damage  to  the 
LRM  or  enclosure  within  a  given  length  of  time.  The  enclosure 
shall  be  capable  of  operating  in  the  applicable  service 
condition  of  MIL-E-5400. 

The  enclosure  and  connector  design  shall  incorporate 
means  to  exclude  radiated  or  conducted  EMI  originating  outside 
the  rack.  The  avionics  as  installed  shall  meet  the  require¬ 
ments  of  MIL-E-6051.  The  enclosure  shall  also  comply  with  the 
applicable  requirements  of  MIL-STD-461.  EMI/EMP  requirements 
shall  be  considered  in  material  selection  for  the  enclosure. 
All  metal  parts  of  the  enclosure  shall  be  maintained  at  air¬ 
frame  potential  by  application  of  suitable  bonding  and  ground¬ 
ing  techniques. 


EMP  hardening  shall  be  applied  to  the  enclosure. 
The  following  techniques  shall  be  used:  (1)  reduction  or 

elimination  of  collected  energy  by  application  of  shielding  and 
grounding  and  bonding;  (2)  reduction  of  incident  energy  on 
equipment  using  protection  devices  (filtering  and  amplitude 
limiting);  (3)  increasing  failure  threshold  of  circuits  by 
component  selection;  (4)  modifying  circuit  function  (functional 
hardening)  to  reduce  susceptibility,  and  (5)  circumvention. 

Electrical  power  shall  be  provided  at  the  enclosure. 
Primary  power  shall  be  3  phase  115  VAC,  400  Hz.  Internal  power 
supplies  shall  provide  voltage  at  the  working  levels  required. 
28  VDC  shall  be  provided  if  no-break  power  is  required.  Fault 
isolation  and  protection  shall  be  provided  within  the 
end  osure . 
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6.2.2  Line  Replaceable  Module 


Sets  of  interchangeable  standard  modules  shall  be 
used.  The  size  of  the  modules  shall  be  such  as  to  allow  re¬ 
placement  of  a  complete  functional  unit  such  as  a  1 7 5 0 A  Proc¬ 
essing  Module.  The  modules  shall  be  designed  to  meet  the 
existing  specifications  for  integrated  circuits,  passive  com¬ 
ponents,  hardware  (connector  assemblies!  and  printed  circuit 
cards.  The  primary  mode  of  heat  transfer  shall  be  by  conduc¬ 
tion  to  slots  in  the  enclosure.  Alternate  cooling  methods 
such  as  heat  pipes  shall  be  used  when  the  heat  dissipation 
requirements  exceed  the  maximum  allowable  for  conduction  cooled 
modules.  The  modules  shall  meet  the  applicable  specifications 
for  thermal,  EMI/EMP  and  structural  integrity.  Standardized 
connectors  with  a  discrete  set  of  pin  numbers  shall  be  used. 
The  connector  design  shall  address  wire  wrap  capability. 
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constraints  and  con rector /modu 1 e 


substrate  interface  compatibility.  The  module  packaging  shall 
allow  use  of  leaded  or  leadless  ceramic  chip  carriers  or  pin 
grid  arrays*  The  substrate  and  chip  carrier  coefficient  of 
thermal  expansion  shall  be  matched  within  specified  limits. 
Appendix  A  contains  detailed  specifications  for  the  3/4  ATR 


modules  to  be  us e 6 . 


6.?. 3  Damage  Tolerance 

The  primary  consideration  shall  be  to  reduce  the 
probability  of  aircraft  loss  due  to  loss  of  flight  essential 
avionics,  with  loss  of  mission  avionics  being  given  secondary 
consideration.  The  avionic  elements  shall  be  physically 
separated  in  different  enclosures  to  minimize  loss  of  any 
function  due  to  battle  damage.  Separation  shall  also  be  pro¬ 
vided  within  the  enclosure  of  critical  independent  elements  to 
limit  single  projectile  damage  effects,. 
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6  „  3  Executive  to  Applications  Interface 

This  section  provides  the  definition  cf  interfaces 
between  application  (mission^  software  and  the  executive  soft¬ 
ware.  The  executive  software  is  described  i  ri  Section  3.7.11, 
3.7.13  and  3.7.13.  In  this  context,  applications  software  is 
defined  as  all  software  not  a  part  of  the  executive  software. 
With  the  exception  of  inter-  module  interfaces,  as  discussed  in 
Section  3. 3. 8. 3,  all  interfaces  made  by  an  applications  module 
are  required  to  be  with  the  executive.  The  executive  to 
applications  interfaces  are,  therefore,  required  to  provide  all 
capabilities  necessary  to  the  participation  of  a  module  in  the 
execution  of  its  parent  function  and  by  extension  of  the 
system.  The  executive  interfaces  described  in  this  section 
provide  for  applications  interfaces  With  the  executive  and  for 
executive  interfaces  with  applications  tasks. 

6.3.1  Applications  Interface  with  the  Executive 

These  interfaces  provide  access  to  the  Kernel  Execu¬ 
tive.  All  applications  tasks  shall  utilize  these  interfaces  to 
the  exclusion  of  any  others  for  all  classes  of  interface  except 
i nter-modu 1 e . 

6.3.2  Executive  Interfaces  with  Applications  Tasks 

The  executive  interfaces  with  applications  tasks 
primarily  to  perform  task  control  operations  resulting  from 
applications  to  executive  interfaces  described  above.  Task 
execution,  termination,  cancellation,  suspension,  and 
restoration  are  the  five  primary  items.  Task  priority  and  the 
event  conditions  associated  with  suspension  are  the  primary 
terms  defining  task  restoration.  An  indirect  interface  with 
applications  tasks  exists  when  the  executive  performs  data  base 
manipulation  operations.  These  operations  occur  under 
direction  of  applications  tasks.  The  Kernel  Executive  handles 
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all  direct  (i.e.,  task  control)  interfaces,  while  the  Kernel 
Executive  coordinates  with  the  Distributed  Executive  to  provide 
indirect  (i.e.,  data  base)  interfaces. 

6.3.3  Usage  of  Executive/Applications  Interface^ 

All  applications  tasks  are  required  to  utilize  the 
applications  to  executive  interfaces  for  all  activities  ex¬ 
ternal  to  the  specific  task.  The  usage  of  executive  to  appli¬ 
cations  interfaces  is  restricted  to  the  execution,  and  may  be 
effected  as  required  by  the  executive.  The  executive  may,  in 
the  interest  of  efficiency  and  modularity,  also  utilize  certain 
of  the  applications  to  executive  interfaces;  for  example,  a 
request  by  a  task  to  invoke  another  task  (the  RUN  applications 
to  executive  interfacel  will  cause  the  executive,  as  a  part  of 
its  processing,  to  enable  the  task  for  execution  (an  executive 
to  application  interface)  as  well  as  request  to  itself  that  an 
event  honoring  the  occurrence  be  issued  f the  SIGNAL 
applications  to  executive  interface). 

Applications  to  executive  interfaces  will  be  imple¬ 
mented  using  packages  (an  Ada  construct!  to  restrict  the  abil¬ 
ity  of  the  applications  task  to  access  information.  The  pack¬ 
age  utilized  by  the  applications  tasks  will  be  a  variation  of  a 
similar  package  utilized  by  the  executive.  The  variation  will 
consist  of  a  restricted  visible  portion  of  the  package.  The 
amount  of  the  package  visible  to  the  applications  task  will  be 
that  which  is  necessary  and  sufficient  to  permit  the  required 
task  access.  For  example,  an  applications  task  which  desires 
only  to  access  data  will  utilize  a  package  with  a  visible 
portion  which  permits  access  only  to  the  data  area  and  to  the 
access  routine.  Since  this  is  a  subset  of  the  package  utilized 
by  the  executive,  it  tends  to  insure  that  the  constructs  and 
routines  accessed  by  an  applications  task  are  actually 
supported  by  the  executive. 
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During  the  period  in  which  Ada  is  not  available, 
interface  constructs  will  be  utilized  during  any  necessary 
simulations  as  part  of  this  effort.  A  language  permitting  a 
measure  of  this  capability  is  MI L-STD-1598B  JOVIAL,  which 
permits  the  use  of  DEFINES  to  implement  the  restricted 
interfaces. 

6 , 4  Non -Homogeneou s  Processing  Pesources 

The  fully  integrated  architectural  concept  includes 
a  set  of  common  data  and  signal  processing  resources  applied  to 
meet  the  processing  requirements  of  all  of  the  sensors  and 
subsystems.  This  set  of  processing  resources  is  recorif  igurabl  e 
and  supports  the  inclusion  of  spare  elements  in  order  to  pro¬ 
vide  higher  probability  of  availability/mission  success  and  to 
support  graceful  degradation.  The  architecture  must  also  sup¬ 
port  the  integration  of  sensors/subsystems  that  are  not  fully 
integrated  and  the  system  implications  of  the  various  levels  of 
sensor/subsystem  integration.  In  addition,  the  architectural 
concept  includes,  as  the  normal  case,  identical  data  and  signal 
processing  resources.  However,  in  a  specific  application  it 
may  not  be  feasible  to  design  all  processing  elements  to 
perform  all  jobs.  Therefore,  this  section  also  addresses  the 
issues  of  non-homoqeneous  processing  resources. 

6  .  A . l  Standalone  Subsystem 

In  the  case  of  a  Standalone  Subsystem,  the  subsystem 
consists  of  a  collection  of  dedicated  sensor  elements  and  a  set 
of  dedicated  signal  and  data  processing  resources  fhardware  and 
software).  These  processing  resources  are  dedicated  to  only 
this  one  job,  and  cannot  participate  in  system  level  resource 
sharing.  This  subsystem  must  be  self-contained  in  that  it  may 
not  be  initially  loaded  by  the  core  system,  and  it  must 
internally  contain  any  fault  tolerant  features  that  it  requires 
to  meet  high  availability /miss  ion  success  goals.  Self- 
contained  functional  subsystems  of  this  nature  shall  interface 
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to  either  the  Mission  Avionics  Multiplex  Bus  or  the  VMS 
Multiplex  Bus,  depending  upon  the  flight  critical  nature  of  the 
function  of  the  subsystem.  In  addition,  if  the  subsystem 
generates  or  uses  as  an  input  a  video  signal,  it  shall  inter¬ 
face  to  the  system  Video  Data  Distribution  Network.  These 
interfaces  are  shown  in  Figure  6. 4. 1-1.  The  subsystem  shall 
possess  well-defined  message  structures  specifying  the  data 
that  it  shall  receive  from  the  multiplex  bus,  and  specifying 
the  data  that  it  shall  place  onto  the  multiplex  bus.  The 
subsystem  shall  be  capable  of  participating  in  the  system  level 
control  procedures  for  operation  of  the  multiplex  bus 
structure,  but  shall  act  only  as  a  remote  device  in  terms  of 
any  higher  level  system  control. 

6.4.2  Shared  Data  Processing  Subsystem 

In  the  case  of  a  subsystem  which  shares  data 
processing,  the  subsystem  consists  of  a  collection  of  dedicated 
sensor  elements  and  a  set  of  dedicated  signal  processing 
resources  (hardware  and  software).  The  data  processing 
functions  associated  with  the  subsystem  are  partitioned  onto 
parts  of  the  array  of  system  level  data  processing  resources. 
These  data  processing  resources  may  be  reassigned  to  alternate 
functions  in  major  mode  changes  or  in  failure  recovery  modes. 
The  signal  processing  resources  are  dedicated  to  only  this  one 
job,  and  cannot  participate  in  system  level  signal  processor 
resource  sharing.  The  signal  processor  resources  in  this  sub¬ 
system  must  be  self-contained  in  that,  they  may  not  be  initially 
loaded  by  the  core  system,  and  they  must  internally  contain  any 
fault  tolerant  features  that  are  required  to  meet  high 
availability/minimum  success  goals.  Subsystems  of  this  nature 
will  interface  to  the  Mission  Avionics  Multiplex  Pus  or  the  VMS 
Multiplex  Bus,  depending  upon  the  flight  critical  nature  of  the 
function  of  the  subsystem.  If  the  sensor  generates  or  uses  as 
an  input  a  video  signal,  it  will  interface  to  the  system  Video 
Data  Distribution  Network.  These  interfaces  are  shown  in 
Figure  6. 4. 2-1.  In  addition,  the  data  processing  software  to 
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support  this  subsystem  shall  reside  on  some  part  of  the  system 
sharable  data  processing  resources.  Communication  between  the 
signal  and  data  processors  shall  be  over  the  Mission 
Avionics/VMS  Multiplex  Bus,  as  will  communications  between  the 
data  processing  function  and  any  users  of  these  subsystem 
results.  The  subsystem  shall  possess  well  defined  message 
structures  specifying  the  data  that  it  shall  receive  and 
transmit  on  the  multiplex  bus.  The  subsystem  shall  be  capable 
of  participating  in  the  system  level  control  procedures  for 
operation  of  the  multiplex  bus  structure,  but  shall  act  only  as 
a  remote  device  in  terms  of  any  higher  level  system  control. 


6,4.3  Shared  Data  and  Signal  Processing  Subsystem 


In  the  case  of  a  subsystem  that  shares  signal  and 
data  processing  the  subsystem  shall  consist  of  a  collection  of 
dedicated  sensor  elements  and  a  set  of  dedicated  sensor  pre¬ 
processing  hardware  custom  to  that  subsystem.  The  signal 
processing  functions  associated  with  the  subsystem  are  parti¬ 
tioned  onto  parts  of  the  array  of  system  level  signal  proces¬ 
sors,  and  the  data  processing  functions  are  partitioned  onto 
parts  of  the  array  of  system  level  data  processors.  Subsystems 
of  this  nature  shall  interface  to  the  Data  Distribution  Network 
to  provide  their  data  to  the  signal  processing  function,  and 
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Control  Network.  These  interfaces  are  shown  in  Figure  6. 4. 3-1. 
Communications  between  the  shared  signal  and  data  processors 
shall  be  on  the  Mission  Avionics  Multiplex  Bus.  The  subsystem 
shall  possess  well-defined  message  structures  for  its  data  sent 
to  the  Signal  Processing,  its  data  received  from  the  Signal 
Processing,  and  the  communications  between  the  shared  Signal 
and  Data  Processing  Resources.  The  subsystem  shall  be  capable 
of  participating  in  the  communications  protocols  for  the  Data 
Distribution  Network  and  the  Sensor  Control  Network. 
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6.4.4  Incomplete  Sensor  Interconnectivity 

The  fully  integrated  system  concept  assumes  that  a 
single  Sensor  Data  Distribution  Network  fully  connects  all 
dedicated  Sensor  preprocessors  to  the  full  array  of  signal 
processors.  In  specific  implementations  it  may  be  desirable  to 
interconnect  these  elements.  This  case  is  shown  in  Figure 
6. 4. 4-1.  In  this  case,  additional  restrictions  on  the 
allowable  assignments  of  functions  onto  signal  processors  must 
be  taken  into  account  in  the  System  Executive  Function. 

6.4.5  Non-HomogeneousData  P_rocgssors 

The  basic  Architectural  Concept  assumes  as  a  default 
case  that  all  data  processing  elements  are  identically  config¬ 
ured,  and  are  the  lowest  el ements  within  which  resource  allo¬ 
cations  can  occur.  However,  in  specific  system  implementations 
it  may  be  necessary  to  include  data  processing  elements  which 
possess  additional  resources  (memory,  throughput,  spare  re¬ 
sources).  As  a  result,  special  consideration  shall  have  to  be 
made  at  the  system  level  with  respect  to  what  functions  can  be 
assigned  to  these  non-standard  data  processors,  and  to  how 
those  functions  can  be  supported  in  failure  modes. 

6.4.6  Non -Homogeneou s  Signal  Processors 


The  basic  Architectural  Concept  assumes  a  bank  of 
identically  configured  Signal  Processors,  any  of  which  can  he 
assigned  to  any  job.  However,  in  a  specific  system  where  one 
job  far  exceeds  the  requirements  of  all  other  jobs,  it  may  be 
necessary  to  consider  more  than  one  configuration  of  Signal 
Processors,  As  a  result,  additional  constraints  shall  be 
introduced  into  the  system  control  process  cn  assignment  of 
functions  to  Signal  Processors  in  both  normal  and  failure 
modes . 
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6.5  ACRONYMS 


ADM 

APSE 

ATR 

BCPE 

BMM 

CNI 

COMSEC 

CSP 

DAIS 

DC  I 

DEN 

DFN 

ECB 

EDC 

EMR 

ESU 

EW 

FFT 

FIR 

FPPE 

FSED 

GM 

GPPE 

GPS 

H/W 

HZ 

IDS 

iir 

INS 

I/O 

ISA 

.111  D  S 

KGM 

LCM 

LRM 

MAMB 

MBPS 

MHZ 

MIPS 

MOPS 

MSEC 

NED 

NSM 

NVBMM 

OFP 


Advanced  Development  Model 

Ada  Programming  Support  Environment 

Air  Transportable  Rack 

Biphase  Correlator  Processing  Element 

Bui k  Memory  Module 

Communications  Navigation  Identification 

Communications  Security 

Common  Signal  Processor 

Digital  Avionics  Information  System 

Dataflow  Control  Interface 

Data  Exchange  Network 

Data  Flow  Network 

Element  Control  Rus 

Error  Detecting  and  Correcting 

Element  Maintenance  Pus 

Element  Supervisor  Unit 

Electronic  Warfare 

Fast  Fourier  Transform 

Finite  Impulse  Response 

Floating  Point  Processing  Element 

Full  Scale  Engineering  Development 

Global  Memory 

General  Purpose  Processing  Element 
Global  Positioning  System 
Ha  rdwa  re 

Hertz  (Cycles  Per  Second) 

Interface  Design  Specification 
Infinite  Impulse  Response 
Inertial  Navigation  System 
Input/Output 

Instruction  Set  Architecture 

Joint  Tactical  Information  Distribution  System 

Key  Generator  module 

Load  Control  Module 

Line  Replaceable  Module 

Mission  Avionics  Multiplex  Bus 

Million  Bits  Per  Second 

Million  Cycles  Per  Second 

Million  Instructions  Per  Second 

Million  Operations  Per  Second 

Mi  1 1 i  -Second 

Nuclear  Event  Detection 

Network  Switch  Module 

Non-volatile  Bulk  Memory  Module 

Operational  Flight  Program 
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PDL 

PE 

PI-BUS 

PVI 

RISA 

ROM 

RT 

SDDN 

SDU 

SEPE 

SI 

SMS 

SP 

S/W 

TCG 

TF/TA/OA 

TM-BUS 

TRANSEC 

TTL 

UCIF 

URT 

VI  “7  r  A  A 

i  /  jun 

VOON 
VHSIC 
VMS 
VP  E 


Program  Design  Language 
Processing  Element 

Parallel  Inter-Module  Communication  Bus 
Pilot  Vehicle  Interface 
Reduced  Instruction  Set  Architecture 
Read  Only  Memory 
Remote  Terminal 

Sensor  Data  Distribution  Network 
Secure  Data  Unit 

Sort  Enhanced  Processing  Element 

Sensor  Interface 

Stores  Management  System 

Signal  Processor 

Software 

Timing  and  Control  Generator 

Terrain  Following/Terrain  Avoidance/ 

Obstacle  Avoidance 

Test  and  Maintenance  Bus 

Transmission  Security 

Transistor-Transistor  Logic 

User  Console  Interface 

Universal  Remote  Terminal 

VHSIC  MIL-STD-1750A 

Video  Data  Distribution  Network 

Very  High  Speed  Integrated  Circuit 

Vehicle  Management  System 

Vector  Processing  Element 
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APPENDIX  A 

GENERAL  SPECIFICATION  FOR  3/4  ATR  MODULE 

1.0  SCOPE. 

1.1  Purpose.  The  purpose  of  this  document  is  to  establish  the 
general  design  requirements  for  the  3/4  ATR  module. 

1.2  Classification.  Standard  electronic  modules  shall  be  of  the 
following  classes  as  specified  in  detail  specifications: 

Class  II  -  For  utilization  where  stringent  environmental 

requirements  are  imposed. 

Class  IV  -  For  utilization  where  class  II  modules  may  be 

exposed  to  radiation. 

2.0  REFERENCED  DOCUMENTS. 

2.1  Issues  of  documents.  The  following  documents,  of  the  issue  in 
effect  on  date  of  invitation  for  bids  or  request  for  proposal,  form  a 
part  of  this  specification  to  the  extent  specified  herein. 

SPECIFICATIONS 


MILITARY 

MIL-A-8625  -  Anodic  Coatings,  for  Aluminum  and  Aluminum 

Alloys. 

MIL-E-16400  -  Electronic,  Interior  Communication  and 

Navigation  Equipment,  Naval  Ship  and  Shore, 
General  Specification  for. 

MIL-S-19500  -  Semiconductor  Device,  General  Specification 

for. 

MXL-C-26074  -  Coating,  Electroless  Nickel,  Requirements 

for. 

MIL-C-28754  -  Connector,  Electrical,  Modular,  and 

Component  Parts,  General  Specification  for. 

MIL-M-28787  -  Modules,  Standard  Electronic,  General 

Specification  for. 

MIL-M-38510  -  Microcircuit,  General  Specification  for. 

MIL-C-39003  -  Capacitors,  Fixed,  Electrolyte  (Solid 

Electrolyte) ,  Tantalum,  Established 
Reliability,  General  Specification  for. 
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MIL-P-50884 

MIL-S-83490 


-  Printed  Wiring,  Flexible,  General 
Specification  for. 

-  Specifications,  Types  and  Forms. 


STANDARDS 

MIL-STD-12 


DOD-STD-IOG 

MIL-STD-129 

MIL-STD-130 

HIL-STD-202 

MXL-STD-242 

VTlf-OTn-nK 

•  *■-  M  ^  4M  §  ** 

MIL-STD-454 

MIL-STD-810 

MIL-STD-863 

MIL-STD-961 

MIL-STD-1285 

M1L~STD~1378 

MIL-STD“1389 


-  Abbreviations  for  Use  on  Drawings, 
Specifications,  Standards  and  in 
Technical  Documents, 


-  Engineering  Drawing  Practices. 

-  Marking  for  Shipment  and  storage. 

-  Identification  Marking  of  U.S.  Military 
Property. 


-  Test  Methods  for  Electronic  and  Electrical 
Component  Parts. 


Electronic  Equipment  Parts  Selected 
Standards  (Part  i  through  Part  8) . 


—  SI - r>1  .  -J - - 

.  .mkcu  Vi .t. j.  -my  Dir' 


itJi.  £,ieui.luiui;  £.quxpmenc. 


Standard  General  Requirements  for  Electronic 
Equipment . 


-  Environmental  Test  Methods. 


-  Test  Methods  and  Procedures  for 
Micr-oelectronics . 

-  Outline  of  Forms  and  Instructi  ns  for  the 
Preparation  of  Specifications  nd  Associated 
Documents . 


-  Marking  of  Electrical  and  Electronic  Parts. 

“  Requirements  for  Employing  Standard 
Electronic  Modules. 

-  Design  Requirements  for  Standard  Electronic 
Modules. 


(Copies  of  specifications,  standards,  handbooks,  drawings,  and 
publications  required  by  manufacturers  in  connection  with  specific 
acquisition  functions  should  be  obtained  from  the  contracting  activity 
or  as  directed  by  the  contracting  officer.) 
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2.2  Other  publications.  The  following  documents  form  a  part  of  this 
standard  to  the  extent  specified  heroin.  Unless  otherwise  indicated, 
the  issue  in  effect  on  the  date  of  invitation  for  bids  or  request  for 
proposal  shall  apply. 

Handbook  H4r2  -  Federal  Supply  Code  for  Manufacturers 
(United  States  and  Canada)  Code  to  Name. 

Handbook  H6  -  Federal  Item  Name  Directory. 

(Applications  for  copies  should  be  addressed  to  the  Defense  Logistics 
Agency,  Defense  Logistics  Service  Center,  Battle  Creek,  Michigan 
49016.) 

BUMED  INSTRUCTION  6270.3-  Personnel  Exposure  Limits  Values  for  Health 

Hazardous  Air  Contaminants. 

(Applications  for  copies  should  be  addressed  to  Naval  District 
Washington,  Supply  and  Fiscal  Department  (Code  514.3),  Washington  Navy 
Yard,  Washington,  DC  20390.) 

2.3  Order  of  precedence.  In  the  event  of  conflict  the  requirements 
specified  in  the  contract,  the  detail  specification,  MIL-M-28787,  this 
specification,  and  the  documents  referenced  herein  shall  govern  in 
that  order. 

3.0  REQUIREMENTS . 

3 . 1  General  requirements 

3.1.1  Specifications  and  standards.  All  modules  shall  be  in 
accordance  with  the  requirements  of  the  detail  specification, 
MIL-M-28787,  this  standard,  and  MIL-STD-1378 .  Exceptions  and 
alternates  or  equivalent  materials,  parts,  processes,  documentation, 
and  so  forth,  shall  be  approved  prior  to  their  use  in  the  design  of  a 
module. 

3.1.2  Mechanical  configuration  requirements.  The  basic  mechanical 
configuration  of  the  module  and  connectors  shall  be  as  shown  on  figure 
1  with  incremental  growth  in  thickness  specified  in  table  I. 

3.1.3  Electrical  configuration  requirements.  Electrical  function  and 
pin  assignments  shall  be  in  accordance  with  table  II.  The  maximum 
allowable  current  for  each  contact  pin  shall  be  3  amperes  dc  or  ac 
rms. 


3. 1.3.1  Preassigned  dedicated  pins;  (see  table  II) .  Pins  assigned 
functions  which  are  not  marked  with  an  asterisk  (*  =  optional)  shall 
be  considered  preassigned  and  dedicated.  Such  pins  shall  be  used  for 
their  preassigned  function  and  used  in  accordance  with  the  rules 
stated  below  or  left  unused. 


INCHES 

MM 

INCHES 

MM 

INCHES 

MM 

.001 

0.03 

.025 

0.64 

.193 

4.90 

.003 

0.05 

.040 

1.02 

.210 

5.33 

.003 

0.08 

.04 

1.0 

.265 

6.73 

.004 

0.10 

.050 

1.27 

.270 

6.86 

.005 

0.1’ 

.0635 

1.59 

.465 

11.81 

.006 

0.15 

.100 

2.54 

4.890 

124.21 

.007 

0.18 

.110 

2.79 

4.940 

125.48 

.010 

0.35 

.115 

3.92 

5.440 

138.18 

.01 

0.3 

.125 

3.18 

5.880 

149.352 

.030 

0.51 

.128 

3.25 

5.885 

149.48 

.033 

0.56 

.19 

4.8 

6.26 

159.0 

6.41 

162.8 

UNLESS  OTHERWISE  SPECIFIED  TOLERANCES  ARE: 
3  placa  dacimals  +  .005 
3  plica  decimals  +  .01 


NOTES: 

1.  Rib  faitura  shall  bs  contained  within  a  .055  inch  (1.40ma)  maximum 
ions  for  tha  .050  inch  ribs  and  a  .130  (3.30mm)  maximum  tons  for  tha 
.135  inch  riba. 

3.  Rib  surfaea  finish  of  35  microinch  or  battar. 


3.  Dimansiona  ara  in  inchaa. 

4.  Metric  aqulvalantr.  ara  qivm n  for  gsnatal  information  only. 

5.  Maxiaun  Component  area  width  of  5.44  inches  allows  minimi  it 
rib  width  of  .22  inches.  Maximum  rib  width  is  .30  inches 
which  allows  component  area  width  minimum  of  5.28  Inches. 


FIGURE  1. 


Module  configuration. 
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FIGURE 

1.  Module  configuration  -  continued. 

A 

B 

c 

D1 

D2 

Module  pitch  1/ 

.3 

.4 

.5 

.6 

.6 

y 

(8) 

(10) 

(13) 

(15) 

(15) 

Module  thickness 

.280 

.380 

.480 

.580 

.580 

(7.11) 

(9.65) 

(12.19) 

(14.73) 

(14.73) 

Maximum  number  pins 

100 

150 

200 

250 

250 

Rib  thickness  (ZZZ) 

.050 

.125 

.125 

.125 

XXX  3/ 

(1-27) 

(3.18) 

(3.18) 

(3.18) 

Dimension  NN  (max) 

.152 

.202 

.252 

.152 

.302 

4/ 

(3.86) 

(5.13) 

(6.40) 

(3.86) 

(7 

.67) 

Dimension  YY  (max) 

.152 

.202 

.252 

.452 

.302 

y 

(3.86) 

(5.13) 

(6.40) 

(11.48) 

(7 

.67) 

*  Note*: 

1/  Pitch  refer*  to  the  distance  between  module  centerlines  for  system 
packaging  purpose*. 

2/  The  .6  inch  (15mm)  pitch  module  configuration  can  increase  in 
thickness  in  .1  inch  (2.5  mm)  increments  with  no  increase  in  contact 
pin  count. 

3/  Module  configuration  D2  can  have  either  one  rib  at  .125  inches 
(3.18mm)  thick  or  two  ribs  at  .050  inches  (1.27mm)  thick  each. 

4/  The  dimensions  are  from  the  center  of  the  two  basic  guide  rib 
profiles  to  locate  connector  lateral  extreme  displacement. 

5/  Dimensions  are  in  inches. 

6/  Metric  equivalents  are  given  for  general  information  only. 
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TABLE  I.  Module  growth. 
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FIGURE  1.  Module  configuration  -  continued. 
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FIGURE  1.  Module  configuration  —  continued. 
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3. 1.3. 2  Optional  pin  assignment:  (see  table  II) .  Pins  assigned 
functions  marked  with  an  asterisk  (*)  shall  be  considered  optional 
pins.  They  shall  be  used  for  their  preassigned  function  or  in 
accordance  with  the  rules  stated  below. 

a.  Functions  shall  appear  on  dedicated  pins  before  they 
appear  on  optional  or  unassigned  pins. 

b.  Functions  shall  appear  on  optional  pins  before  they  appear 
on  unassigned  pins. 

c.  Fixed  voltages  of  different  potentials  shall  not  be 
assigned  to  adjacent  pins. 

d.  Any  unused  pins  shall  be  isolated  (not  connected  to  any 
other  used  or  unused  pins) . 

e.  Pins  assigned  as  dedicated  or  optional  pins  may  be 
considered  as  unassigned  only  after  all  the  following 
conditions  exist: 

(1)  The  pin  is  not  required  for  the  preassigned 
function. 

(2)  There  is  a  lack  of  pin  availability. 

(3)  All  other  pin  assignment  requirements  are  met. 


f.  Optional  pin  locations  shall  be  used  for  nonassigned 
functions  before  dedicated  pins  are  used  for  nonassigned 
functions. 

g.  The  analog  ground  shall  only  be  used  when  two  types  of 
grounds  are  required.  These  two  types  of  ground  pins 
shall  not  be  connected  together  internal  to  the  module. 
Power  ground  shall  be  used  if  only  one  type  of  ground  is 
required. 

3. 1.3. 3  Connector  pin  assignments.  The  use  of  connector  pin 
assignments  of  table  II  shall  be  as  follows: 

a.  For  a  100  pin  input/ output  connector  use  rows  A  and  E. 

Pins  are  to  be  numbered  consecutively. 

b.  For  a  150  pin  input/output  connector  use  rows  A>  B,  and  E. 
Pins  are  to  be  numbered  consecutively. 

c.  For  a  200  pin  input/output  connector  use  rows  A,  B,  D,  and 
E.  Pins  are  to  be  numbered  consecutively. 
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d.  For  a  250  pin  input/output  connector  use  rowo  A  through  E. 

e.  Figure  1  and  Table  I  and  II  demonstrate  configurations  for  250  pins 
maximum.  For  a  connector  vith  more  than  250  pins  add  a  second  row  C 
for  300  pins  and  a  third  row  C  for  350  pins. 

3.1.4  Thermal  requirements.  All  modules  shall  be  designed  to  be  cooled  through 
the  ribs  and  shall  be  capable  of  being  cooled  by  the  rib  with  no  other  heat  loss. 

3.1.5  Environmental  requirements.  The  following  environmental  requirements  apply 
eKcept  as  modified  In  3.2.7. 

3. 1.5.1  Operating  environmental  requirements.  Modules  shall  withstand  without 
damage,  the  operating  environmental  requirements  of  MIL-M-28787, 

3. 1.5. 2  Nonoperating  environmental  requirements .  Modules  shall  withstand,  without 
damage,  the  nonoperating  environmental  requirements  of  MIL-M-28787. 

3. 1.5. 3  Hydrogen  atmosphere.  Modules  using  metal  oxide  thick  film  resistors  shall 
be  capable  of  passing  the  hydrogen  atmosphere  test  specified  in  MIL-M-28787. 

3 . 7  Detailed  requirements. 

3.2.1  Module  construction.  Modules  shall  conform  to  the  design,  construction, 

and  physical  dimensions  specified  herein  and  in  MIL-M-28787.  Modules  of  a  given  key 
code  shall  be  mechanically  and  electricall  interchangeable  regardless  of  the  system 
in  which  they  are  used  when  operated  within  the  required  module  design  limits. 

3. 2. 1.1  Configuration.  The  basic  module  size  has  a  span  of  5.88  inches  (149.4  mm) 
maximum,  a  thickness  of  280  Inches  (7.11  mm)  maximum,  and  Is  6.68  inches  (169.7  min) 
maximum  in  total  height.  Modules  may  increase  in  thickness  in  accordance  with  table 
I.  Dimensions  and  tolerances  shall  be  as  specified  on  figure  1. 

3. 2. 1.2  Circuitry .  The  module  shall  have  a  minimum  clearance  of  .015  inch  (0.38  mm) 
around  all  edges  of  the  substrate  or  printed-wiring  board.  The  printed -wiring  board 
shall  be  further  reduced  to  allow  for  insertion  of  module  extractor  and  prevent 
component  damage  during  module  extraction. 

3. 2.1. 3  Module  depth.  The  only  parts  of  the  module  that  shall  extend  below  the  inter¬ 
face  plane  are  the  keying  pins,  contact  pins,  and  pin  shields  unless  otherwise  spec¬ 
ified  in  the  detailed  module  specification. 

3. 2. 1.4  Module  frame.  The.  module  frame  shall  include  module  rib  structures  and 
extraction  capability.  The  module  frame  may  also  include  protective  covers  and  thermal 
clamps  mounted  to  the  rib  structures,  A  module  with  thermal  clamps  mounted  to  it 

may  violate  the  module  envelope  shown  on  figure  1,  However,  the  clamps  must  be 
removable  and  the  module  without  the  thermal  clamps  mounted  to  it  must  fit  within 
the  envelope.  The  covers  shall  assist  in  EMI  and  CBR  protection,  and  shall 
not.  violate  the  module  envelope. 
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3. 2 .1.4.1  Module  rib  structure.  The  basic  module  configuration  shall 
have  a  minimum  of  two  ribs:  one  located  at  the  alpha  end  and  one 
located  at  the  beta  end  of  the  module.  The  module  ribs  shall  perform 
the  following  functions: 

a.  Alignment  during  insertion  or  extraction. 

b.  Retention. 

c.  Cooling. 

The  rib  configuration  and  location  is  shown  on  figure  1.  Modules  of 
.3,  .4  and  .5  inch  pitch  shall  have  two  ribs;  one  located  at  the  alpha 
end  and  one  located  at  the  beta  end  of  the  module.  These  ribs  shall 
be  located  as  indicated  in  figure  1  and  table  I.  Modules  of  .6  inch 
pitch  shall  have  either  two  or  four  ribs.  If  four  ribs  are  utilized, 
two  shall  be  located  at  the  alpha  end  and  two  shall  be  located  at  the 
beta  end  of  the  module.  These  ribs  shall  be  located  as  indicated  in 
figure  1  and  table  I.  If  only  one  rib  is  used  on  each  end,  it  shall 
be  located  as  indicated  in  figure  1  and  table  I.  All  ribs  shall  have 
a  thickness  as  shown  on  table  1. 

3. 2. 1.4. 1.1  Rib  strength.  The  individual  module  ribs  shall  withstand 
a  torque  of  10  inch-pounds  (1.13  newton-meters)  minimum  maintained  for 
10  to  15  seconds.  There  shall  be  no  detrimental  effect  to  the 
mechanical  integrity  of  the  module. 

3. 2. 1.4. 2  Module  extractor  interface.  Modules  shall  either  have  two 
extractor  holes  located  as  shown  on  figure  1  or  an  alternate  means  of 
insertion/extraction.  The  latter  may  violate  the  module  envelope.  If 
extractor  holes  are  present,  modules  having  a  thickness  of  2.090 
inches  (53.09nun)  or  greater  shall  have  two  sets  of  extractor  holes. 

The  second  set  shall  be  located  within  the  last  .3  inch  (8  nun)  of  the 
module  and  meet  the  location  requirements  shown  on  figure  1. 

3, 2. 1.5  Module  header  structure.  The  module  header  shall  perform  the 
following  functions: 

a.  Module  identification. 

b.  Module  insertion. 

c.  Component  protection. 

d.  Teat  point  access. 

3. 2. 1.5.1  Modulo  identification.  The  module  identification  header 
shall  have  the  configuration  and  marking  as  specified  on  figure  2. 

3. 2. 1.5. 2  Module  insertion.  The  header  structure  shall  be  capable  of 
withstanding  ioo  pounds  (445  newtons)  of  insertion  force. 
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3. 2.1. 5. 3  Component  protection.  The  header  structure  shall  be  designed  to  help 
prevent  component  damage  during  exposure  to  Insertion  and  extraction. 

3. 2. 1.5. 4  Test  point  access.  The  module  header  shall  provide  readily  accessible 
test  points,  however,  all  final  electrical  acceptance  testing  shall  be  performed 
through  the  (Input/output)  connector  pins  on  the  module.  All  individual  modules 
shall  be  designed  such  that  the  removal  of  the  header  shall  in  no  way  effect  the 
proper  functioning  of  the  module. 

3. 2. 1.6  Pin  shields.  Modules  shall  be  provided  with  pin  shields  to  protect  the 
contact  pins.  Modules  shall  have  pin  shields  adjacent  to  each  outside  row  of  module 
pins.  Pin  shields  shall  be  of  a  nonconducting  material  or  if  of  a  conducting  material, 
the  outside  surface  of  the  shield  shall  be  treated  in  a  manner  that  will  prevent 
conduction  into  the  base  conducting  material. 

3. 2. 1.6.1  Pin  Bhleld  retention.  The  pin  shield  shall  withstand  a  force  of  A  poundB 
(18  newtons)  minimum  maintained  for  10  to  15  seconds  without  separation  from  the 
module  or  damage  to  the  pin  shield.  This  requirement  shall  be  met  after  exposure 

to  all  manufacturing  process  temperatures  including  preconditioning. 

3. 2. 1.7  Module  connector.  All  connectors  shall  be  in  accordance  with  the  requirements 
specified  herein  and  in  MIL-C-28754.  The  basic  module  connector  shall  have  two 

rows  of  50  metal  bayonet  type  contact  pins.  Modules  of  .A,  .5  and  .6  inch  (10,  13, 
and  15  mm)  pitch  may  increase  contact  pin  quantity  to  three,  four,  and  five  rows 
of  50  contact  pins  with  all  rows  of  50  pins  to  be  complete.  Multiple  growth  modules 
may  increase  contact  pin  row  quantities  with  each  row  of  pins  complete.  Up  to 
7  rows  of  50  pins  is  maximum  allowable.  Modular  connectors  which  support  digital., 

BP,  and  fiber  optic  contacts  are  permitted. 

3. 2. 1.7.1  Connector  location.  The  location  of  connectors  shall  be  as  shown  on 
figure  1.  Each  connector  shall  have  contacts  identified  by  numbers  indicating  the 
first  and  last  pin  of  the  row  closest  to  the  pin  shield  as  shown  on  figure  1. 

3. 2. 1.7. 2  Module  contact  pins.  The  number  of  contact  pins  on  the  module  shall  be 
specified  in  the  detail  specification.  The  contact  configuration  is  controlled  only 
on  that  part  of  the  contact  pin  protruding  from  the  module  connector  surface  (the 

■4  c  r>1  ino^ 

~  w-  v  f  —  /  - 

3.2.1. 7.2.1  Contact  pin,  location.  The  location  of  contact  pins  shall  be  as  shown 
on  figure  1. 

3. 2. 1.7. 2. 2  Connector  contact  integrity.  Each  contact  pin,  as  mounted  in  the  connector, 
shall  withstand  an  axial  force  of  20  ounces  (5.6  newtons)  minimum  applied  in  2  to  10 
seconds  along  the  length  of  the  contact  blade  in  either  direction  and  maintained 

for  10  to  15  seconds. 
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3. 2. 1.8  Module  keying.  Each  module  is  assigned  an  alpha  or  alpha  numeric  key  code. 

The  first  letter  indicates  the  style  and  angular  position  of  a  keying  pin  in  the 
alpha  keying  pin  location  and  the  last  letter  designates  the  style  and  angular  position 
of  a  keying  pin  in  the  beta  location.  The  following  paragraphs  provide  a  sample 
keying  scheme. 

3. 2. 1.8.1  Keying  pin  locations.  There  are  two  keying  pin  locations  on  each  module 
designated  alpha  and  beta.  The  alpha  and  beta  keying  pin  locations  are  near  the  lowest 
and  highest  numbered  connector  pins  in  the  first  row,  respectively,  as  shown  on 
figure  3.  Keying  pins  on  a  mulitple  growth  module  should  be  located  at  the  extreme 
ends  of  the  first  module,  increment  having  a  connector. 

3.2.1.8.2  Keying  pin  orientation.  Keying  pins  shall  be  oriented  to  agree  with  the 
basic  angle  specified  for  the  module  by  the  code  letters  on  figures  4,  5,  or  6. 

Figure  4  illustrates  the  module  axis  and  specifies  the  tolerance  for  angular  positioning. 

3. 2. 1.8. 3  Keying  pin  styles.  Keying  pin  styles  shall  be  in  accordance  with 
figure  7. 

3. 2. 1.8. 4  Keying  pin  sets.  Only  the  keying  pin  styles  and  keying  pin  locations 
in  table  III  are  permitted. 

3. 2. 1.8. 5  Keying  pin  integrity  requirement.  When  installed  in  the  module,  the 
keying  pins  shall  meet  the  following  integrity  requirements. 

3. 2. 1.8. 5.1  Keying  pin  torque.  Each  key  pin  shall  withstand  a  torque  of  20  inch- 
ounces  (0.14  newton-meter)  minimum  applied  in  2  to  10  seconds  and  maintained  for  10 
to  15  seconds. 

3. 2. 1.8. 5. 2  Keying  pin  pullout.  Each  key  pin  shall  withstand  a  pullout  force  of 

9  pounds  (40  newtonfi)  minimum  applied  in  2  to  10  seconds  and  maintained  for  10  to 
15  seconds. 

3. 2. 1.8. 5. 3  Keying  pin  pushout.  Each  keying  pin  shall  withstand  a  pushout  force 
of  40  pounds  (178  newtons)  applied  in  2  to  10  seconds  arid  maintained  for  10  to 

15  seconds.  The  force  ehall  be  applied  in  the  oppositie  direction  as  the  force  in 
3, 2. 1.8. 5. 2. 

3. 2. 1.8. 5. 4  Keying  pin  cantilever  load.  Each  key  pin  shall  withstand  a  cantilever 
load  of  10  pounds  (44  newtons)  minimum  applied  in  2  to  10  seconds  and  maintained  for 

10  to  15  seconds. 

3. 2. 1.9  Printed  wiring  boards  and  printed  wiring  assemblies.  Printed  wiring  boards 
and  printed-wiring  assemblies  shall  conform  to  the  following  requirements. 
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FIGURE  3.  Keying  pin  location. 
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FIGURE  5.  Style keying  chart  {viewing  connector  as  shown  on  figure  3) 
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FIGURE  7.  Module  keying  pin  styles. 
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3. 2.1. 9-  9  Rigid  printed-wiring  boards .  The  design  of  rigid  printed-wiring  boards 
shall  conform  to  the  requirements  specified  in  MIL-STD-275-  Equivalent  materials, 
processes,  requirements,  and  so  forth,  shall  be  utilized  only  when  approved  by  the 
SEMP-QAA.  These  equivalent  materials,  processess,  requirements,  and  so  forth,  shall 
be  documented  and  forwarded  to  the  SEMP-QM  for  review  and  approval. 

3. 2. 1.9- 2  Printed-wiring  assemblies.  The  design  of  printed-wiring  assemblies  shall 
conform  to  the  requirements  specified  in  MIL-STD-1389 ,  appendix  F.  Equivalent 
materials,  processes,  requirements,  and  so  forth,  shall  be  utilized  only  when 
approved  by  the  SEMP-QAA.  These  equivalent  materials,  processes,  requirements, 

and  so  forth,  shall  be  documented  and  forwarded  to  the  SEMP-QAA  for  review  and 
approval . 

3. 2. 1.9* 3  Flexible  printed  wiring  and  assemblies.  Flexible  printed  wiring  and 
assemblies  shall  conform  to  the  requirements  of  MIL-P-5088H ,  type  B.  Performance, 
quality  assurance,  and  workmanship  shall  be  in  accordance  with  MIL-P-5088U . 

3.2.1.10  Materials .  Materials  used  in  the  manufacture  of  modules  shall  conform  to 
the  requirements  specified  herein  and  shall  be  certified  in  accordance  with  applicable 
specifications  where  required,  when  a  material  is  not  specified,  a  material  shall 

be  used  which  will  enable  the  module  to  satisfy  the  requirements  specified  herein. 
Acceptance  or  approval  of  a  constituent  material  shall  not  be  construed  as  an 
assurance  of  the  acceptance  of  the  finished  product. 

3.2.1.10.1  Use  of  toxic  material.  Materials  which  are  capable  of  producing  dangerous 
gasses  or  other  harmful  toxic  effects  as  defined  in  BUMED  INSTRUCTION  6270.3  over 

the  temperature  range  of  -55  C  to  +  125  C,  while  burining,  shall  not  be  used  unless 
suitable  nontoxic  material  is  not  available. 

3.2.1.10.2  Use  of  flammable  material.  Materials  used  in  modules  shall  be  in  accordance 
with  the  requirements  of  MIIr-STD-1+5^ ,  requirement  3,  and  shall  be  self  extinguishing 
within  5  seconds  after  removal  of  flame. 

3.2.1.10.3  Use  of  material  affected  by  fungus.  Materials  used  in  modifies  shall  not 
support  fungal  growth  when  tested  in  accordance  with  MIL-STD-810,  method  508. 

3.2.1.11  Finishes  and  protective  treatments.  The  finishes  and  protective  treatment 
of  surfaces  shall  enable  the  mod-ole  to  meet  the  requirements  specified  herein. 

Acceptance  or  apporval  of  a  finish  or  protective  treatment  shall  not  be  construed 

as  an  assurance  of  the  acceptance  of  the  finished  product.  MTL-E-I6UOO  shall  be  used 
in  the  selection  of  finishes  and  protective  treatments. 

3.2.1.11.1  Module  surface  finish.  The  surface  finish  of  the  module  shall  be  free 
of  any  imperfections  that  have  a  detrimental  effect  upon  the  performance  of  the  module. 
The  surface  of  the  ribs  shall  be  machined  smooth  and  25  microinch  ( 0 . 0006h  mm)  or 
better. 
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3.2.1.11.2  Copper  and  copper  composite  frame  plating.  All  copper  and 
copper  composite "frames  shall  be  electroless  nickel  plated  in 
accordance  with  MIL-C-26074,  class  1,  grade  A. 

3.2.1.11.3  Aluminum  frame  plating.  All  aluminum  frames  shall  receive 
an  anodic  treatment,  in  accordance  with  MIL-A-8625,  type  III,  class  2, 
black. 


3,2.1.11.4  Connector  body  plating.  Any  aluminum  parts  utilized  on 
the  connector  shall  receive  an  anodic  treatment  in  accordance  with 
MIL-A-8625,  type  III,  class  2,  black. 

3.2,1. \1.5  Conformal  coating.  The  conformal  coating  shall  be  in 
accordance  with  the  requirements  of  MIL-STD-1389,  appendix  F.  The 
conformal  coating  shall  be  a  continuous,  homogeneous,  fully  cured 
material  which  covers  all  components,  leads,  and  circuitry,  except 
grounding  surfaces.  The  coating  thickness  may  vary  with  the 
irregularity  of  the  module  surface. 

3.2.1.12  Weight.  Modules  shall  be  designed  for  minimum  weight 
consistent  with  reliable  circuit  operation. 

3.2.2  Module  marking.  All  modules  shall  be  identified  and  marked 
with  appropriate  identifiers  as  specified  herein.  Figure  2  specifies 
the  marking  areas  for  the  following  information: 

a.  Key  code. 

b.  Module  part  number,  revision  letter  and  amendment  number. 

c.  Certification  mark. 

d.  Module  name. 

e.  Serial  number. 

f.  Manufacturer's  information. 

1.  Manufacturer's  identification. 

2,  Date  code. 

g.  Connector  contact  identification. 

h.  Electrostatic  discharge  marking  (ESD) . 

i.  RAM/ROM  test  code. 

j.  ROM/PROM  program  code. 
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All  markings  excluding  key  code  shall  be  a  minimum  of  0.06  inch  (1.5 
mm)  high  and  shall  be  located  as  shown  on  figure  2  and  applied  in 
accordance  with  MIL-STD-130.  All  marking  shall  be  in  a  contrasting 
color  to  the  surrounding  module  area.  All  marking  shall  be  permanent 
and  legible  in  accordance  with  MIL-STD-1285. 

3.2.2. 1  Module  key  code.  The  key  code  assigned  to  each  module  shall 
be  marked  as  shown  on  fTgure  2.  The  marking  is  located  at  the  alpha 
end  of  the  module  on  the  top  surface  of  the  identification  header. 

3. 2. 2. 2  Module  part  number  and  revision  status.  The  module  part 
number,  revision  letter,  and  amendment  number  shall  be  marked  as  shown 
on  figure  2.  This  information  is  located  in  the  same  area  as  the 
manufacturer's  information.  All  standard  module  part  numbers  will  be 
assigned  by  the  SEMP-DRA.  Requests  for  part  number  assignment  shall 
be  prepared  and  submitted  in  accordance  with  MIL-STD-1378 .  Modules 
documented  with  MIL-STD-961  military  specifications  shall  be  marked 
with  the  revision  status  of  the  specification  to  which  the  modules 
were  tested.  This  marking  shall  be  as  follows: 
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For  example,  a  module  could  be  marked  M28787/123-1  A(l)  . 

Environmental  class  I  shall  be  indicated  by  a  -1,  environmental  class 
II  shall  be  indicated  by  a  -2,  environmental  class  III  shall  be 
indicated  by  a  -3,  and  environmental  class  IV  shall  be  indicated  by  a 
-4.  The  detail  specification  revision  letter  and  amendment  number  are 
not  a  part  of  the  module  part  number  and  shall  bo.  left  blank  if  none 
exists.  The  example  part  number  is  not  intended  to  designate  a  length 
of  field  requirement.  The  length  of  the  part  number  will  vary 
according  to  the  applicable  detail  specification. 

3 . 2 . 2 . 2 . 1  Module  part  number  and  7/evision  status  for  special  modules . 
Part  numbers  for  special  modules,  as  defined  in  MIL-STD-1378 ,~~wlll  be 
assigned  as  directed  by  the  acquisition  activity.  Special  modules 
shall  be  marked  with  the  revision  status  of  the  document  to  which  the 
modules  were  built. 

3. 2. 2. 3  Certification  mark.  All  modules  that  meet  the  requirements 
of  MIL-M-28787  and  the  detail  specifications  shall  have  the  Government 
certification  mark  "JAM"  or  "J"  marked  as  shown  on  figure  2. 
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3. 2. 2. 4  Module  item  name.  Each  nodule  shall  have  its  iten  name 
marked  in  the  area  shown  on  figure  2.  The  item  name  and 
manufacturer's  information  shall  be  oriented  such  that  both  are 
readable  from  the  same  point  of  view.  The  name  marked  on  the  module 
shall  agree  with  the  item  name  in  the  title  of  the  detail 
specification,  however,  abbreviation  in  accordance  with  MIL-STD-12  is 
permissible.  The  module  design  activity  is  responsible  for  generation 
of  an  approved  item  name.  The  item  names  in  H6  shall  be  used  if  they 
appropriately  describe  the  module.  When  H6  does  not  list  an  item  name 
which  appropriately  describes  the  module,  an  item  name  shall  be 
developed  in  accordance  with  MIL-STD-961.  The  SEMP-DRA  is  the 
approval  source  for  item  names. 

3. 2. 2. 5  Manufacturer's  information.  The  following  information  shall 
be  marked  on  each  module  at  the  locations  shown  on  figure  2.  No  other 
module  manufacturer's  part  number  shall  be  marked  on  the  module. 

3. 2. 2. 5.1  Manufacturer's  identification.  Each  module  shall  be  marked 
with  either  the  manufacturer's  identification  code  or  manufacturer's 
name.  The  manufacturer's  code,  if  utilized,  shall  be  a  numerical  code 
as  listed  in  H4-2.  A  test  code  assigned  by  the  SEMP-QAA  for  each 
vendor's  integrated  circuit  type  used  shall  be  marked  on  each  RAM/ROM 
module  in  the  area  specified  for  the  manufacturer's  identification. 

3. 2. 2. 5. 2  Serial  number.  Each  module  shall  have  a  serial  number 
including  vendor's  designation.  The  serial  number  is  located  -^n  the 
top  surface  of  the  same  fin/header  used  for  marking  the  key  code.  The 
serial  number  shall  consist  of  five  digits  with  significant  digits 
prefixed  with  zeros  as  required.  The  serial  number  shall  be  affixed 
to  the  module  prior  to  electrical  acceptance  test. 

3. 2. 2. 5. 3  Serial  number  sequence.  Each  module  manufacturer  shall 
serialize  each  module  manufactured  under  the  requirements  of  the  SEMP. 
The  serial  number  for  any  given  key  code  will  start  with  number  1  v.nd 
continue  in  numerical  sequence  as  many  times  as  the  module  is 
manufactured  regardless  of  contract  or  customer. 

3. 2. 2. 5. 4  Vendor  designation.  A  single  or  double  alpha  character 
shall  be  assigned  to  each  module  manufacturer  contracted  to  produce 
modules.  The  designation  shall  be  prefixed  to  the  module  serial 
number.  Request  for  a  vendor  designation  shall  be  submitted  to  the 
SEMP-DRA. 


3. 2. 2. 6  Date  code.  Each  module  shall  be  marked  with  a  four  digit 
date  code  designating  the  year  and  the  week  of  manufacture.  The  first 
two  digits  of  the  code  shall  be  the  last  two  numbers  of  the  year  and 
the  third  and  fourth  digits  of  the  code  shall  be  the  calendar  week. 
When  the  number  of  the  week  is  a  single  digit,  it  shall  be  preceded  by 
a  zero.  The  date  code  for  a  given  module  shall  be  the  calendar  week 
in  which  the  last  major  manufacturing  assembly  process  occurred  prior 
to  the  final  acceptance  inspection  plus  or  minus  one  week. 


A-23 


SPA  90099001 A 
16  January  1987 


3. 2. 2. 7  Electrostatic  discharge  (ESP) .  Modules  that  are  determined 
by  the  SEMP-QAA  to  require  special  handling  due  to  sensitivity  to 
electrostatic  discharge  (ESD)  by  prior  knowledge  of  device 
technologies  or  by  testing  to  MIL-M-28787  shall  be  marked  in  the  areas 
shown  on  figure  2  with  the  sensitive  electronic  device  symbol 
specified  in  MIL-STD-1285.  If  the  minimum  symbol  size  specified  in 
MIL-STD-129  can  not  be  met,  the  size  shall  be  maximized  for  the 
particular  fin  configuration. 


3.2.3  Module  mechanical  requirements.  The  following  mechanical 
requirements  apply. 

3. 2. 3.1  Module  integrity.  Each  module,  with  the  connector  assembled 
shall  withstand  without  damage  or  separation  on  minimum  axial  force 
normal  to  the  interface  plane  equal  to  100  pounds  (445  newtons)  on 
insertion  and  4  ounces  (1.11  newton)  per  contact  on  extraction.  The 
total  computed  force  shall  be  applied  to  the  module  to  simulate  module 
insertion  and  extraction.  The  force  shall  be  applied  in  2  to  lo 
seconds  and  maintained  for  10  to  15  seconds. 

3. 2. 3. 1.1  Module  extractor  integrity.  The  extractor  structure  shall 
provide  the  strength  required  to  extract  the  module  and  meet  the 
requirements  of  3.2.3. 1. 

3. 2. 3. 1.2  Module  header  integrity.  The  header  structure  shall 
provide  the  strength  required  to  install  the  module  and  meet  the 
requirements  of  3. 2. 1.5. 2. 

3. 2. 3. 2  Module  torque .  The  module  shall  be  capable  of  withstanding  a 
6  inch-pound" (0. 68  newton-meter)  torque  applied  in  2  to  10  seconds  and 
maintained  for  10  to  15  seconds  in  both  directions  along  the  header  in 
a  direction  perpendicular  to  the  plane  of  the  header  without 
detrimental  effect  to  the  mechanical  or  electrical  properties  of  the 
module.  During  the  time  the  torque  is  applied,  the  module  shall  be 
rigidly  supported  within  a  zone  between  the  interface  plane  and  0.5 
inch  (13  mm)  above  the  interface  plane. 

3.2.3. 3  Module  cantilever  load.  The  module  shall  be  capable  of 
withstanding  a  force  of  2  pounds  (9  newtons)  applied  perpendicular  to 
the  header  height  along  the  centerline  midway  between  the  two 
extractor  holes.  The  force  shall  be  applied  in  two  directions  and 
shall  be  applied  in  2  to  10  seconds  and  maintained  for  10  to  15 
seconds  without  detrimental  effect  to  the  header  structure. 

3. 2. 3. 4  Durability.  The  module  shall  be  capable  of  withstanding  500 
cycles  of  mating  and  unmating  with  no  degradation  of  module 
performance.  The  module  shall  also  be  capable  of  withstanding  500 
cycles  of  lateral  displacement  to  simulate  the  use  of  thermal  clamping 
devices.  The  lateral  displacements  may  be  included  in  the 
insertion/extraction  sequences  or  completed  after  the 
insertion/extraction  cycling. 

3.2.4  Module  electronic  design  requirements.  Modules  shall  be 
designed~In  accordance  with  the”  following  requirements. 
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3. 2. 4.1  Personnel  safety.  Modules  with  voltages  exceeding  30  volts 
(direct  current  or  alternating  current  root  Bean  square)  to  ground 
shall  have  exposed  conductive  frame  surfaces  (except  for  pin  shields 
and  key  pins)  connected  to  either  the  0  volt  or  chassis  ground  contact 
pin.  The  maximum  resistance  between  the  ground  pin  and  the  exposed 
conductive  frame  surfaces  shall  be  1  ohm. 

3. 2. 4. 2  Powered  socket.  The  detail  specification  for  modules 
containing  device  technologies  which  cannot  be  protected  by  the  module 
design  during  removal  or  insertion  into  a  powered  socket  must  contain 
caution  notices  of  susceptability  to  damage. 

3. 2. 4. 3  Component  selection.  Electronic  components  and  hardware  used 
in  modules  shall  have  a  demonstrated  quality  level  and  environmental 
performance  equivalent  to  or  better  than  that  of  available  military 
parts.  Nonhermetically  sealed  packaged  relays  and  semiconductor 
devices  having  hermetically  sealed  equivalents  shall  not  be  used. 

3. 2. 4. 3.1  Germanium  semiconductors.  Germanium  semiconductors  shall 
not  be  used . 

3. 2. 4. 3. 2  Discrete  semiconductors.  Discrete  semiconductors  shall  be 
in  accordance  with  the  requirements  of  MIL-S-19500  and  shall  be 
selected  according  to  the  following  priority  list.  Devices  listed  in 
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a.  MIL-S-19500  JANTX  devices  listed  in  MIL-STD-242. 

b.  Other  MIL-S-19500  JANTX  devices. 

c.  Devices  being  considered  for  a  MIL-S-19500  JANTX 
detail  specification.  Devices  shall  be  equal  to  or 
better  than  MIL-S-19500  devices. 

d.  Other  devices.  Devices  shall  be  equal  to  or  better  than 
MIL-S-19500  devices. 

3. 2. 4. 3. 3  Integrated  circuits.  Integrated  circuits  shall  be  in 
accordance  with  the  following  requirements, 

3. 2. 4. 3. 3.1  Quality  requirements.  Integrated  circuits  shall  be  in 
accordance  with  the  requirements  of  MIL-M-38510,  class  B.  The  module 
supplier  shall  use  MIL-M-38510  JAN  QPL  devices  when  available  or 
procure  other  devices  with  equivalent  specifications.  All  equivalent 
specifications  shall  be  submitted  to  the  SEMP-QAA  for  approval  prior 
to  initial  qualification.  Equivalent  specifications  shall  include: 

a.  The  screening  shall  be  in  accordance  with  MIL-STD-883, 
method  5004,  class  B. 

b.  Quality  conformance  shall  be  demonstrated  in  accordance 
with  MIL-STD-883,  method  5005,  groups  A,  B,  C,  D,  and  E 
(if  applicable),  class  B. 
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c,  Generic  data  is  acceptable  for  demonstrating  quality 

conformance  in  accordance  with  MIL-STD-383,  method  5005, 
groups  C  and  D,  class  B.  A  generic  family  shall  be 
electrically  and  structurally  similar  integrated  circuits. 
They  are  designed  to  perform  the  same  type  of  basic 
circuit  function  using  the  same  basic  circuit  element 
configuration  and  differ  only  in  the  number  of 
identically  specified  circuits  which  they  contain. 

They  are  designed  for  the  same  supply,  bias,  and  signal 
voltages  and  for  input-output  compatibility  with  each 
other  under  an  established  set  of  loading  rules.  They 
are  enclosed  in  packages  of  the  same  construction  and 
outline,  differing  only  in  the  number  of  active  external 
package  leads  included  or  used  and  made  from  the  same 
materials  by  use  of  the  same  processes, 

3. 2. 4. 3. 3. 2  Selection  requirements.  Integrated  circuits  shall  be  in 
accordance  with  the  requirements  of  MIL-M-38510  and  shall  be  selected 
according  to  the  following  priority  list.  Devices  listed  in  b,  c,  and 
d  shall  be  approved  by  the  SEMP-QAA  prior  to  use. 

a.  MIL-M-38510  JAN  microcircuits  listed  in  MIL-STD-242. 

b.  Other  MIL-M-38510  JAN  microcircuits. 

c.  DESC  Selected  Item  Drawing  Microcircuits. 

d.  other  microcircuit  devices  shall  be  equal  to  or 
better  than  MIL-M-38510  JAN  devices, 

3. 2. 4. 3. 3. 3  Restricted  usage.  Memory  devices  of  identical  size  and 
configuration  from  different  suppliers  shall  not  be  mixed  on 
individual  modules. 


3. 2, 4. 3. 3. 4  Substitution  requirements.  A  MIL-M-38510  part  may  be 
substituted  if  the  quality” "requirements  are  met  for  a  vendor  approved 
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3. 2. 4. 3. 4  Passive  components.  Passive  components  shall  be  selected 
according  to  the  following  priority  list.  Devices  listed  in  c  and  d 
shall  be  approved  by  the  SEMP-QAA  prior  to  use. 


a.  Established  reliability  (ER)  specification  parts  (minimum 
level  P  if  multiple  sources  exist)  listed  in  MIL-STD-242. 

b.  ER  parts  (minimum  level  M  if  required  to  achieve  multiple 
sources)  listed  in  MIL-STD-242. 

c.  Other  ER  parts. 

d.  Conventional  military  specification  parts. 
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e,  ER  parts  that  use  the  Weibull  failure  rate  prediction 

method,  such  as  MIL-C-39003,  shall  require  a  "B"  minimum 
failure  rate  level. 

3. 2. 4. 3. 5  Hybrid  microcircuits.  Hybrid  microcircuits  shall  be  in 
accordance  with  the.  requirements  of  MIL-STD-883  and  MIL-M-38510,  or 
equivalent. 


a.  Hybrid  microcircuits  which  are  contained  in  packages 
having  an  inner  seal  perimeter  of  2.0  inches  (51  mm) 

or  greater  shall  be  in  accordance  with  the  requirements 
of  MIL-STD-883 ,  method  5008. 

b.  Hybrid  microcircuits  which  are  contained  in  packages 
having  a  seal  perimeter  of  less  than  2.0  inches  (51  mm) 
shall  be  in  accordance  with  the  requirements  of 
MIL-STD-883,  method  5004  and  5005,  class  B,  or  method 
5008. 


All  equivalent  specifications  shall  be  submitted  to  the  SEMP-QAA  for 
approval  prior  to  initial  qualification. 

3.2.5  Thermal  requirements.  The  following  thermal  requirements 

apply. 
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critical  component  temperatures  are  not  exceeded  when  modules  are 
operated  at  typical  power  at  the  maximum  thermal  interface  temperature 
for  the  appropriate  class. 


3. 2. '5. 2  Typical  power  dissipation.  Typical  power  dissipation  means 
tbs  maximum  recommended  power  dissipation  under  nominal  module 
operating  condition.  Typical  power  values  for  semiconductor  devices 
are  derived  from  contractor  developed  characterization  data  (if 
available)  or  secondly,  from  vendor  data  sheets.  When  the  typical 
power  dissipation  for  a  component  cannot  be  determined,  the  maximum 
power  dissipation  for  worst  case  module  operating  conditions  shall  be 
used. 


3 *2. 5. 3  Component  temperatures.  The  following  requirements  for 
critical  component  temperature  (CCT)  and  transient  critical  component 
temperature  (TCCT)  apply. 

3. 2. 5. 3.1  CCT.  The  CCT  for  semiconductor  devices  dissipating  2.5 
watt3  or  less  typical  power  shall  be  70  C  junction  for  classes  I  and 
III  and  C  junction  for  classes  II  and  IV.  For  semiconductors 
dissipating  more  than  2.5  watts  typical  power,  the  CCT  may  increase  15 
C/watt  or  a  maximum  of  15  C  above  that  specified  for  less  than  2.5 
watt  devices.  For  all  other  components,  the  CCT  shall  be  equal  to  the 
individual  components  maximum  specified  operating  temperature  minus  30 
C  and  shall  be  specified  on  the  component's  hottest  external  area. 
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3. 2. 5. 3. 2  TCCT.  The  TCCT  for  all  devices  shall  be  the  appropriate 
CCT  plus  20  C. 

3.2.6  Environmental  requirements .  The  module  shall  meet  the 
environmental  requirements  of  MIL-M-28787,  for  class  II  or  class  IV 
modules  except  as  modified  herein. 

3. 2. 6.1  Life  test.  When  tested  in  accordance  with  paragraph  4.1.1 
the  end  of  life  requirements  shall  be  in  accordance  with  the  detailed 
module  specification. 

3. 2. 6. 2  Inclination.  When  specified  in  the  detailed  module 
specification,  modules  shall  be  capable  of  proper  operation  during  the 
test  requirements  of  MIL-M-28787.  Modules  employing  heat  pipes  shall 
meet  the  requirements  for  operating  temperature  after  being  subjected 
to  the  test  requirements  of  paragraph  4.1.2. 

3. 2. 6. 3  Thermal  shock.  Modules  shall  be  capable  of  proper  operation 
and  shall  show  no  deterioration  after  being  subjected  to  the  test 
requirements  of  paragraph  4.1.3. 

3. 2. 6. 4  Salt  fog.  Modules  shall  be  capable  of  proper  operation  and 
shall  show  no  deterioration  after  being  subjected  to  the  test 
requirements  of  paragraph  4.1.4. 

3.2.7  Documentation  requirements.  Individual  module  designs  shall  be 
fully  documented " in  accordance  with  this  specification.  Module 
specifications  prepared  in  accordance  with  this  document  shall  be  the 
governing  documents  used  for  the  procurement  and  testing  of  modules, 
information,  in  addition  to  that  required  by  this  specification,  may 
be  added  to  the  detailed  module  specification  as  deemed  necessary  for 
procurement  and  testing  of  a  particular  module. 

3.2.7. 1  specification  classification.  Individual  module 
specifications  shall  be  prepared  in  accordance  with  MIL-STb-961. 

3. 2. 7. 2  Types  of  specifications.  Module  specifications  shall  be 
either  Type  C2a  Format  or  Type  C2b  Format  in  accordance  with 
MIL-S-83490  for  standard  or  special  modules  respectively.  All 
specifications  shall  be  prepared  as  book  form  drawings  on  "A”  size 
drawing  forms  in  accordance  with  DOD-STD-IOO. 

3.2.8  Preconditioning.  All  modules  shall  be  subjected  to 
preconditioning  in  accordance  with  the  following: 

a.  The  module  shall  be  subjected  to  nonoperating  temperature 
cycling  for  a  minimum  of  ten  complete  cycles  of 
temperature  variation.  A  cycle  shall  consist  of  15 
minutes  at  temperature  extremes  of  +85  c,  or  above,  and 
-55  C,  or  below,  with  a  maximum  transfer  time  between 
temperature  extremes  of  5  minutes.  A  cycle  may  begin  at 
either  temperature. 


A-2  0 


SPA  90099001 A 
16  January  1987 


b.  Upon  completion  of  the  temperature  cycling,  the  module 
shall  meet  the  Initial  electrical  requirements  specified 
in  the  detailed  module  specification.  Preconditioning 
shall  be  completed  prior  to  the  25  C  electrical 
inspection. 

3.2.9  Life  expectancy.  Modules  shall  be  designed  for  a  minimum  life 
expectancy  of  100,000  hours  operation  at  maximum  temperature  for  the 
appropriate  class. 

3.2.10  Workmanship.  Workmanship  shall  be  of  such  quality  that  the 
module  will  comply  with  the  requirements  specified  in  the  detailed 
module  specification  and  MIL-STD-454,  requirement  9. 

4.0  QUALITY  ASSURANCE  PROVISIONS. 

4.1  Exceptions.  The  quality  assurance  provisions  shall  be  in 
accordance  with  MIL-M-28787  except  for  the  following: 

4.1.1  Life.  The  module  shall  be  mounted  in  a  suitable  test  fixture 
and  operated  for  a  period  of  not  less  than  500  hours  at  85  C  thermal 
interface  temperature  as  specified  in  the  detail  module  specification. 
Upon  completing  the  life  test,  and  while  still  at  85  C,  the  module 
shall  meet  the  end-of-life  85  C  electrical  requirements  defined  in  the 
individual  module  specification.  The  module  shall  then  be  returned 
nonoperating  to  a  thermal  interface  temperature  of  25  C  at  a  chamber 
temperature  rate  not  to  exceed  1  C  per  minute.  After  a  stabilization 
period  of  four  hours,  the  module  shall  be  tested  to  and  meet  the 
end-of-life  requirements  specified  in  the  detailed  module 
specification. 

4.1.2  Heat  pipes.  Modules  employing  heat  pipes  for  cooling  shall 
meet  operating  temperature  requirements  when  the  module  heat  sink  is 
inclined  at  an  angle  of  90  degrees  from  the  horizontal. 

4 •1*3  Thermal  shock.  The  module  shall  be  tested  in  accordance  with 
MIL-STD-202,  test  method  107,  for  400  cycles,  -55  C  to  +125  C.  The 
module  shall  pass  ail  electrical  tests.  There  shall  be  no  evidence  of 
deterioration  or  physical  damage  after  thermal  shock. 

4.1.4  Salt  fog.  The  module  shall  be  tested  in  accordance  with 
MIL-STD-810,  method  509,  procedure  I.  The  module  shall  be  examined 
with  the  aid  of  a  10-power  magnification  following  a  gentle  wash  in 
warm  (37  c  +  5  C)  water  upon  removal  from  test  chamber  (to  remove 
visible  salt  deposits) ,  and  storage  for  48  hours  at  room  ambient 
conditions  to  allow  for  evaporation  of  excess  moisture.  Failure 
mechanisms  shall  include  pits,  crack  formations,  intergranular  attack, 
ate.:  that  is,  any  concentrated  attack  that  weakens  the  cross  section, 
surface  corrosion  products  shall  not  be  evidence  of  failure.  The 
module  shall  be  subjected  to  all  electrical  tests.  Any  failures  due 
to  corrosion  or  corrosion  products  shall  be  cause  for  failure. 
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5,0  PACKAGING. 

5.1  General .  Packing  and  packaging  of  modules  shall  be  in  accordance 
with  klb-M-28787  (see  paragraph  5.0). 

6.0  NOTES . 

6.1  Intended  use.  Modules  specified  herein  are  intended  for  use  in 
military  systems  and  subsystems. 

6 . 2  Definitions. 

6.2.1  Standard  Electronic  Modules  Program  (SEMP) .  A  design 
standardization  program  which  has  for  its  goal  the  development  of 
functional  electronic  modules  from  which  a  variety  of  complex  military 
electronic  systems  may  be  built. 

6.2.2  SEMP  Design  Review  Activity  (SEMP-DRA) .  The  activity 
responsible  'for  the  review  and  classification  of  module  designs  is  the 
Naval  Avionics  Center,  6000  E.  21st  Street,  Indianapolis,  Indiana 
46218  (Code.  965). 

6.2.3  SEMP  Quality  Assurance  Activity  (SEMP-QAA) .  The  activity 
responsible- for  specification  and  design  review,  correlation,  vendor 
audits,  and  qualification  testing  is  the  Naval  Weapons  Support  Center, 
Crane,  Indiana  47522  (Code  603) . 

6.2.4  Key  code.  An  alpha  or  alpha  numeric  (e.g.  A4A)  designator  used 
to  identify  the  style  and  angular  position  of  the  keying  pins. 

6.2.5  Alpha  end.  The  end  of  the  module  nearest  the  lowest  numbered 
pin. 

6.2.6  Beta  end.  The  end  of  the  module  farthest  from  the  lowest 
numbered  pin. 

6.2.7  Critical  component  temperature  (CCT).  The  maximum  temperature 
allowed  for  any  component ~ln  the  module  while  the  module  is  operating 
at  maximum  class  temper ature. 

6.2.8  Transient  critical  component  temperature  (TCCT) .  The  maximum 
temperature  allowed  for  any  component  in  the  module  while  the  module 
is  operated  at  maximum  class  temperature  plus  20  C  without  exceeding 
any  individual  component  TCCT, 

6.2.9  End-of-life  tolerance.  The  minimum  and  maximum  limits  for  any 
particular  module  characteristic  after  being  subjected  to  100,000 
hours  operation  established  at  an  ambient  temperature  of  25  C  +  5  C  as 
well  as  over  the  entire  temperature  range  specified  for  the  module. 

6.2.10  Powered  socket.  A  socket  whose  terminals  are  connected  to 
active  power  supplies,  control  circuits,  loads,  and  signal  sources  to 
simulate  system  requirements. 


v\\ 


r.  v  .■ 

V.\ 
•  .  * 


?*,  V-, 
^  V 


v.\< 


A-30 


SPA  90099001 A 
16  January  1987 


Copying  1 
(1)  each 
complete 


VHSIC  Phase  2  INTEROPERABILITY  STANLARDS 


PI-BUS  SPECIFICATION 


September  8,  1986 


Version  2.0 


IBM 

Honeywell 

TRU 


Copyright  1985,  1986 
IBM  Honeywell  TRU 

n  printed  form  is  permitted  without  payment  of  royalty  provided  that 
reproduction  is  done  without  alteration,  (2)  each  reproduction  is 
and  (3)  the  copyright  notice  is  included. 


Pl-bus  Specification 


Vara  ion  2.0 


CONTENTS 


l&slum  .Tills  Page 

1.0  SCOPE  . . ;  .  .  1-1 

1.1  SCOPE .  1-1 

1.2  PURPOSE .  1-1 

1.3  INTENDED  APPLICATION .  1-1 

1.4  CLASSIFICATION .  1-1 

2.0  mPPLICABLE  DOCUMENTS  . . . .  2-1 

2.1  GOVERNMENT  DOCUMENTS .  2-1 

2.2  NON-GOVERNMENT  DOCUMENTS .  2-1 

3.0  DEFINITIONS  . .  . .  3-1 

3.1  ITEM  DEFINITION .  3-1 

3.2  TERM  DEFINITIONS .  3-3 

4.0  PHYSICAL  LAYER  . . .  4-1 

4.1  INTRODUCTION . .  4-1 

4.2  LINE  DEFINITION .  4-1 

4.2.1  Nomenclature,  .....  .  4-1 

4.2.2  Bused  Signal  Line?;,  ...........  4-1 

4.2.3  Bus  Clock.  . .  4-8 

4.2.4  Module  Identification .  4-8 

4.3  ELECTRICAL  REQUIREMENTS  .  4-9 

4.3.1  Backplane  Requirements.  ...  .  4-9 

4.3.2  Module  Requirements.  ...........  4-10 

5.0  DATA  LINK  LAYER  .  5-1 

5.1  INTRODUCTION .  5-1 

5.2  GENERAL  REQUIREMENTS . 5-1 

5.2.1  Introduction.  .  5-1 

5.2.2  Protocol  State  Transitions.  .  5-4 

5.2.3  Generic  Message.  .  5-7 

5.3  DETAILED  REQUIREMENTS . 5-25 

5.3.1  Introduction  5-25 

5.3.2  Bus  State  Definitions . 5-25 

5.3.3  Bus  Mastership.  . 5-29 

5.3.4  Message  Sequences  .  5-38 

5.3.5  Exception  Sequences.  .  5-67 

5.3.6  Wait . 5-75 

5.3.7  Data  Link  Facilities.  5-77 

5.3.8  Initialization.  . .  5-87 

5.3.9  Error  Detection,  Recovery  And  Diagnostics.  5-68 


il 

& 

► 

k 


v* 

;■ 
V 
*  1 


•f- 


*1 


?  ■ 
K 


13-2 


Pi-bus  Specif (cation 


Version  2.0 


CONTENTS  (continued) 

LIST  OF  ILLUSTRATIONS 


f i aura  Title  Page 

Figure  3-1.  Conceptual  (lode!  Of  Bus  And  Modules  .  3-2 

Figure  4-1.  Set-up  And  Hold  Timing  . 4-12 

Figure  4-2.  Signal  Output  Test  Circuit  ...  .  4-13 

Figure  4-3.  Output  Signal  Timing  .  4-13 

Figure  5-1.  Pl-bus  Protocol  State  Diagram  .  5-7 

Figure  5~2.  Header  Word  A  Format  -  Data  Lines  . 5-13 

Figure  5-3.  Single  Slave  Acknowledge  Word  Format  -  Data  Lines  .  .  5~18 

Figure  5-4.  Multiple  Slave  Status  Word  Format  (AWMO)  -  Data  Lines  5-21 

Figure  5“5.  Multiple  Slave  Status  Word  Format  -  Data  Check  Lines  .  5-22 

Figure  5-6.  Tenure  Pass  Message  Header  Word  Formats  ...  .  5-34 

Figure  5-7.  Parameter  Write  Header  Word  Formats  .  5-39 

Figure  5-8.  Block  Message  -  Short  Header  Word  Formats  ......  5-45 

Figure  5~9.  Block  Message  -  Extended  Header  Word  Formats  .....  5-53 

Figure  5-10.  Bus  Interface  Message  Header  Word  Formats  ......  5~63 

Figure  5-11.  Multicast.  Acknowledge  Register  Word  Format  .....  5-80 

Figure  5-12.  Control  Register  Word  Format  .  .....  5-81 

Figure  5~i5,  nodule  Capabilities  Register  Word  Format  ......  5~82 

Figure  5-14.  Vie  Interval  A  Register  Word  Format  .........  5~83 

Figure  5-15.  Vie  Interval  B  Register  Word  Format  . 5-84 

Figure  5~16.  Vio  Priority  Register  Word  Format  .  ,  .  5~85 

Figure  5-17.  Logical  Slave  Identification  Register  Word  Format  .  .  5~87 


b-3 


r.’i 


r.* 


Pi-bus  Specification 


Version  2.0 


CONTENTS  (continued) 

LIST  OF  TABLES 

IflbJLg  Title  £ii.ris 

Table  4~1.  Pl-bus  Signal  Line  Requirements  By  Type  And  Class  .  .  4-3 

Table  4-2.  Pi-bus  Cycle  Typos  and  Valid  Symbols  . .  4-6 

Table  4-3.  Acknowledge  Line  Valid  Symbols  ......  .  4-7 

Table  5-1.  Pi-bus  Communications  Sequences  ...........  5-2 

Table  5-2.  Pi-bus  Protocol  States  .  .....  5-3 

Table  5-3.  Generic  Pi-bus  Message  Sequence  ............  5-9 

Table  5-4.  Message  Type  Codes  . . 5-14 

Table  5-5.  Access  Type  Codes  . 5-15 

Table  5-6.  Multiple  Slave  Acknowledge  Symbol  Formats  (Four  Words)  5-23 

Table  5-7.  Multiple  Slave  Acknowledge  Symbols  (Four  Words)  ....  5-24 

Table  5-8.  Bus  State  Definitions  . . .  . . 5-26 

Table  5-9 .  Vie  Sequence  . . 5-30 

Toblo  5-10.  Module  Vie  Code  Format  -  Data  Linos  . . 5-32 

Table  5-11.  Module  Vie  Code  Format  -  Data  Check  Lines  . 5-33 

Table  5-12.  Tenure  Pass  Message  Sequence  .  ...  5-36 

Table  5-13.  Parameter  Write  Sequence  -  Type  16  Single  Slave  .  .  .  5-40 

Table  5~14.  Porameter  Write  Sequence  -  Type  16  Multiple  Slave  .  .  5-41 

Table  5-15.  Parameter  Write  Sequence  -  Type  32  Single  Slave  .  .  .  5-42 

Table  5~16.  Parameter  Write  Sequence  -  Type  32  Multiple  Slave  .  .  5-43 

Table  5-17.  Block  Message  -  SH  Sequence  -  Type  16  Single  Slave  ,  5-46 

Table  5-18.  Block  Message  -  SH  Sequence  -  Type  16  Multiple  Slave  5-47 

Table  5-19.  Block  Message  -  SH  Sequence  -  Type  32  Single  Slave  .  5-49 

Table  5-20.  Block  Message  -  SH  Sequence  -  Type  32  Multiple  Slave  5-50 

Table  5-21.  Block  Message  -  EH  Sequence  -  Type  15  Single  Slave  .  5-54 

Table  5-22.  Block  Message  -  EH  Sequence  -  Type  16  Multiple  Slave  5-56 

Table  5-23.  Block  Message  -  EH  Sequence  -  Type  32  Single  Slave  .  5-58 

Table  _5~24.  Block  Message  -  EH  Sequence  -  Type  32  Multiple  Slave  5-60 

Table  5-25.  Bus  Interface  Message  Sequence  -  Type  16  Single  Slave  5-64 

Triblw  5-26.  Bus  Interface  Message  Sequence  -  Type  16  Multiple  Slave  5-65 

Table  5~27 ,  Suspend  -  Short  Dote  Sequence  -  Type  16  Single  Slave  5-69 

Table  5-28.  Suspend  -  Short  Data  Sequence  -  Type  32  Single  Slave  5-70 

Table  5~29.  Suspend  -  Extended  Data  Sequence  -  Type  16  Single  Slave  5-71 

Table  5-30.  Suspend  -  Extended  Date  Sequence  -  Type  32  Single  Slava  5-72 

Table  5-31.  Suspend  -  Type  16  Multiple  Slave  . 5-73 

Table  5-32.  Suspend  -  Type  32  Multiple  Slave  . .  .  5-74 

Table  5-33,  Abort  Sequence  . 5-75 

Table  5-34.  Data  Link  Register  Address  Space  . 5~7B 

Table  5-35.  Interpretation  and  Response  for  Uncorrectabl e  Invalid 

Symbols  . . . 5~8  9 

Table  5-36.  Slave  Response  to  Cycle  Type  Sequence  Deviations  .  .  .  5-91 

Table  5-37.  Cycle  Type  Duviation  Response  Definitions  ......  5-92 

Table  5-38.  Sequence  Error  Response  .....  . 5-93 

Table  5-39.  Semantic  Errors  . . 5-94 


LI  -4 


rl-bus  Specification 


Version  2.0 


ABSTRACT 


This  specification  defines  e  1 i n«ar>  multi-drop*  synchronous  bus 
(Pi-bus)  which  supports  digital  message  communications  between  up  to  32  mod¬ 
ules  residing  on  e  single  backplane.  Messages  are  transferred  datum  serial 
end  bit  parallel  using  a  datum  size  of  10  bits  (single  tiord)  or  32  bits  (double 
word). 

Tb-a  Pi-bus  uses  a  master-slave  communications  protocol  which  allows  the 
bus  master  to  read  data  from  one  slave  or  write  data  to  any  number  of  slaves  in 
a  single  message  sequence.  Messages  may  be  routed  to  particular  modules  using 
either  logical  or  physical  addressing.  A  number  of  independent  messages  may 
be  transmitted  during  a  bus  master's  tenura.  The  message  formats  provide  a  32 
bit  virtual  address  range  for  each  module. 

The  PX~bus  p-otocol  specifies  e  set  of  bus  state  transitions  which  con¬ 
trol  the  communication  sequences  end  allow  the  bus  to  operate  in  a  pipelined 
manner  at  the  maximum  clock  rate  allowed  by  the  bus  signal  propagation  delay. 
Master-slave  handshaking  is  provided  with  a  minimal  performance  penalty  by 
operating  the  slave  modules  in  synchronism  with  the  master  end  using  bus  state 
look-ahead. 

A  technique  far  ternporari ly  suspending  low  priority  block  data  transfers 
to  reduce  bus  acquisition  latency  for  higher  priority  messages  is  defined. 

Bus  mastership  may  be  changed  either  by  direct  assignment  or  by  priority 
arbitration.  The  protocol  defines  12B  logical  levels  of  message  priority  and 
32  levels  of  physical  priority. 

Extensive  signal  line  end  sequence  error  detection  capability  is  incor¬ 
porated  into  the  bus  definition.  In  addition*  an  optional  singlQ  line  error 
correction  capability  is  specified. 
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PREFACE 


This  document  was  jointly  prepared  by  IBM,  Honeywell  and  TRU  in  partial 
fulfillment  of  Contract  Data  Requirements  List  (CDRL)  item  A011  for'work  being 
performed  under  VHS1C  Phase  2  Submicrometer  Technology  Development  contracts 
DAAK20-85-C-0367,  F33615-84-C-1500  and  N00039-85-C-0111 ,  respectively. 
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Section  1 
SCOPE 


1.1  SCOPE. 

This  specification  states  the  physical,  electrical,  functional  and  psi — 
formance  requirements  defined  for  the  Pi-bus. 

1.2  PURPOSE. 

The  purpose  of  this  standard  is  to  establish  requirements  for  the  Pi-bus 
and  facilitate  interoperability  of  modules  which  use  the  Pi-bus. 

1.5  IHT ENDED -APPLICATION. 

The  Pi-bus  is  intended  to  provide  a  master-slave  communications  path  for 
I  transferring  digital  messages  between  a  sat  of  up  to  32  modules  residing  on  a 
single  backplane. 


1.4  CLASSIFICATION, 

Bus  configurations  and  modules  which  conform  to  this  standard  may  be  any 
of  the  types,  classes  and  features  specified  below: 


Typa  16 
Type  32 
Class  ED 
Class  EC 
Feature  so 
Feature  ms 


16  bit  date  transfers 
32  bit  data  transfers 
Error  Detecting 
Error  Correcting 
51ave  Only  operation 
Master  and  Slave  operation 


Buses  and  modules  shall  be  classified  according  to  their  maximum  capabil¬ 
ities.  Bus  sequences  shall  be  classified  according  to  the  Type  or  Class  of 
transfer  actually  used. 


All  modules  and  buses  shall  be  capable  of  operating  in  Type  16.  Class  ED 
mode.  Type  32  and  Type  16  modules  shall  be  interoperable  on  a  Type  32  bus  whe¬ 
re  the  Type  32  modules  may  communicate  using  16  or  32  bit  transfers  but  only  16 
bit  transfers  are  used  whenever  a  Type  16  module  is  an  active  participant. 
All  active  modules  on  a  given  bus  shall  operate  in  the  same  class. 
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Section  2 

APPLICABLE  DOCUMENTS 


2.1  GOVERNMENT  DOCUMENTS. 

The  following  documents  of  the  exact  issue  shown  form  e  part  of  this 
spaci f i cat i on  to  the  extent  specified  herein.  In  the  event  of  conflict 
between  the  documents  referenced  herein  and  the  contents  of  this 
speci f i catt on,  the  contents  of  this  specification  shall  be  considered  a  super¬ 
seding  requirement. 

*  None. 

2.2  NON-GOVERNMENT  DOCUMENTS. 

The  following  documents  of  the  exact  issue  shown  form  a  part  of  this 
specification  to  the  extent  specified  herein.  In  the  event  of  conflict 
between  the  documents  referenced  herein  and  the  contents  of  this 
specification,  the  contents  of  this  specification  shall  be  considered  a  super — 
seding  requirement. 


None . 
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Section  3 
DEFINITIONS 

The  definitions  listed  Herein  shell  apply  to  the  PX-bus  end  Pi-bus  mod¬ 
ules. 


3.1  ITEH  PEF-lMUatU, 

I  The  Pi-bus  is  a  linear,  multi-drop  communications  medium  which  transfers 

J  datum  serial#  bit  parallel  information  among  up  to  32  modules  residing  on  a 
single  backplane.  The  datum  size  may  be  a  single  word  or  a  double  word. 

Pi-bus  modules  are  those  modules  which  implement  the  slave  only  or  mas¬ 
ter  and  slave  portions  of  the  Pi-bus  protocol  as  specified  herain. 


Figure  3-1#  illustrates  the  Pi-bus  and  Pi-bus  modules.  Conceptually, 
each  module  consistn  of  e-  device  which  performs  the  application  specific  func¬ 
tion  of  the  module  and  a  Bus  Interface  which  implements  the  Pi-bus 
master — slave  communications  protocol. 


The  device  portion  of  each  module  is  modeled  as  a  virtual  memory  space 
with  a  32  bit  addrass  range.  The  Bus  Interface  is  modeled  as  a  separate  memory 
space  with  an  8  bit  Data  Link  register  address  range.  A  separate#  8  bit  virtu- 
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modules  to  participate  in  a  particular  communications  sequence  as  slave(s). 
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Figure  3~ 


.  Conceptual  Model  Of  Bus  And  Modules 


MODULE  VIRTUAL  ADDRESS  SPACE  =  2**8 

-  PHYSICAL  SLAVE  ID  0-31 

-  inr.im  «ii  avf  in  37  -  255 
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The  definitions  given  below  shall  apply  to  the  Pi-bus.  and  Pi-bus 
Modules. 


The  concatenation  operator  for  groups  of 
bi  ts. 


I  active  lus  interface 


arbitration 


assert  (signal) 


asserted  (signal) 


backplane 


broadcast 
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bus  master 


bus  tenure 


contender 


A  Bus  Interface  that  is  connected  to  the  bus 
media*  and  is  currently  capable  of  (and  not 
inhibited  from)  participating  in  bus  trans¬ 
actions. 

The  process  by  which  a  single  bus  master  is 
selected  from  competing  potential  bus 
masters. 

The  action  of  changing  the  state  of  a  bus 
signal  line  from  released*  logic  0*  to 
asserted,  logic  1,  or  of  ensuring  that  the 
line  remains  in  the  asserted  state. 

The  logic  )  state  of  a  bus  signal  line.  The 
least  positive  of  the  two  states  of  e  bus 
signal  line. 

A  motherboard  comprising  wiring  for  the  bus 
and  connectors  to  the  modules  attached  to  the 
bus. 

A  mode  of  operation  where  the  bus  master 
transmits  data  to  all  modules  during  a  single 
transfer. 

nmi APtfu  nnHnl o( « 


request  for  bus  mastership  to  the  time  at 
which  that  module  becomes  bus  master. 

The  module  currently  in  control  of  the  bus. 

The  period  between  the  time  a  bus  master 
gains  control  of  the  bus  and  the  time  at 
which  control  is  released. 

A  potential  bus  master  module  which  is 
actively  vying  for  bus  mastership. 


dtvit;* 


The  portion  of  a  module,  excluding  the  Bus 
Interface,  which  does  the  application  depend- 
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doubla  word 

linear  bus 
message 

nodule 

multicast 

non-transfer  cycle 


partial  message 


post  (symbol  1 


release  (signal) 


released  (signal) 


ant  function  of  tha  module. 

An  ordered  set  of  32  bits  operated  on  as  a 
pair  of  words  or  as  a  single  unit.  The  most 
significant  bit  of  a  double  word  is  labeled 
bit  31  and  the  least  significant  is  labeled 
bit  0. 

A  bus  with  o  single  shared  medium  segment. 

A  set  of  sequences  starting  with  a  header 
and  terminating  when  all  bus  actions  indi¬ 
cated  by  that  header  have  been  performed. 

An  entity  which  is  addressable  via  the  bus 
and  has  a  single  connection  to  the  bus. 

A  mode  of  operation  where  the  master  trans¬ 
mits  data  to  more  than  one  slave  during  a 
single  transfer. 

A  bus  cycle  that  immediately  follows  a  bus 
cycle  in  which  a  valid  Wait  is  asserted  or 
one  of  the  VZ,  HZ,  DZ  or  HAZ  cycles  specified 
in  the  protocol.  Information  on  the  Data 
lines  is  not  used  during  a  non-transfer 
cycle. 

A  sequence  starting  with  a  header  and  termi¬ 
nating  prematurely  due  to  a  suspend,  abort  or 
other  exception  indication  prior  to  a  normal 
completion . 

The  action  taken  to  assert  and/or  release 
individual  bus  lines  within  one  particular 
group  of  bus  lines  such  that  either  the  asso¬ 
ciated  symbol  appears  on  the  group  or  another 
symbol  appears  that  is  the  result  of  individ¬ 
ual  line  ORing  of  simultaneously  posted  sym¬ 
bols. 

The  action  of  ceasing  to  assert  a  logic  1  on 
a  bus  signal  line.  The  action  of  releasing  a 
signal  line  produces  a  change  in  the  state  of 
the  signal  line  only  if  no  module  is  assert¬ 
ing  that  si gnal . 

The  logic  0  state  of  a  bus  signal  line  pro¬ 
duced  when  no  module  asserts  the  signal  asso¬ 
ciated  with  that  line.  The  more  positive  of 
the  two  states  of  a  bus  signal  line  relative 
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sequence 

sieve 

symbol 


transfer 

I 


word 


to  the  0  Volt  logic  reference. 

A  transact  ion  comprising  a  number  of  ordered 
transfers  performing  one  intended  function. 

A  module  which  is  selected  by  thtf  bus  master 
to  participate  in  a  message  sequence. 

A  unit  of  information  on  a  particular  group 
of  bus  lines,  as  represented  by  a  particular 
binary  encoding  of  bits.  A  valid  symbol  is 
one  which  conforms  to  the  signal  definitions 
herein  including  correct  parity>  Hamming 
encoding  or  redundant  coding  as  applicable. 

A  set  of  elemental  operations  on  the  bus 
which  results  in  the  communication  of  a  bit 
parallel  datum  unit  between  the  current  bus 
master  and  the  selected  slave(s).  The  datum 
unit  is  either  16  bits  (Type  16)  or  32  bits 
(Type  32).  See  sequence. 

An  ordered  set  of  16  bits  operated  on  as  a 
unit.  The  most  significant  bit  is  labeled 
bit  15  and  the  least  significant  bit  is 
labeled  bit  0. 
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Saction  4 
PHYSICAL  LAYER 


4.1  INTRODUCTION. 

The  physical  layar  of  tha  PT~bus  is  specified  herein.  Signal  lines 
required  to  implement  tha  Pi-bus  are  do  fined,  including  those  used  for  signal 
line  error  detection  and  correction.  Tha  electrical  characteristics  of  tha 
module  interfaces  and  backplane  are  specified  and  timing  definitions  are  pre¬ 
sented. 

4.2  LINE  DEFINITION. 

The  Pi-bus  signal,  clock  and  module  identification  lines  are  defined  in 
this  section.  In  addition,  the  encoding  used  to  achieve  signal  line  error 
detection  and  correction  is  specified  by  definition  of  the  valid  symbols 
allowed  for  each  signal  line  group. 

4.2.1  NOMENCLATURE. 

Lines  shall  be  designated  by  name  or  by  capital  letter  abbreviations, 
e.g.  Data  or  D.  Where  a  set  of  related  lines  are  represented  by  the  same  name, 
the  lines  within  the  set  shall  be  differentiated  by  number  with  the  least  sig¬ 
nificant  bit  numbered  0.  The  nomenclature  for  single  lines  shall  be  the  let¬ 
ter  abbreviation  for  the  line  name  followed  by  the  bit  number  enclosed  in  <  >, 
e.g.  D<0>.  The  nomenclature  X<m..n>  shall  be  the  abbreviation  for  the  set  of 
lines  Xm  to  Xn.  inclusive,  where  X  is  the  letter  abbreviation  for  the  line 
name  and  m  and  n  are  the  most  and  least  significant  bit  numbers,  respectively. 
Thus,  D<7..0>»  represents  the  least  significant  eight  Data  lines.  In 
addition,  X<i,j,...,k>  shall  be  an  abbreviation  for  the  set  of  lines  X<i>, 
X<j>,...,  X<k>.  Thus  D<5,3,1,7>  stands  for  the  set  of  lines  D<5>,  D<3>,  D<1>, 
and  D<7>. 

P(X)  shall  designate  tha  parity  (modulo  2  sum)  of  the  set  of  signal 
lines  defined  by  X.  Thus  PC D<15 . . 0 > , DC<0> )  designates  the  parity  of  the  six¬ 
teen  bits  present  on  the  Datt  lines  plus  the  Data  Check  line  and 
P ( D<15 . . 0> , DC<0> ) =0  represents  even  parity  over  the  specified  lines. 

4.2.2  BUSED  SIGNAL  LINES. 

AH  Pi-bus  signal  lines  shall  be  implemented  as  wired-or  lines  bused 
between  modules  on  a  common  backplane.  Modules  and  buses  shall  implement 
those  bused  signal  lines  specified  for  their  particular  Type  and  Class  by 
Table  4-1.  Any  implemented  bus  signal  lines  which  are  not  required  during  an 
operation  of  a  particular  Type  and  Class  shall  be  released  during  that  opera¬ 
tion. 


Symbols  posted  onto  signal  lines  shall  be  valid  symbols  as  specified  in 
this  section,  except  that  during  diagnostic  bus  operation  some  invalid  symbols 
are  allowed  as  specified  in  ”5. 3.9.5  Diagnostics.." 
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As  s  required  device  function.  Pi-bus  modules  shall  provide  a  command 
path  independent  of  the  Pi-bus  which  provides  e  way  to  force  all  PX-bus  signal 
lines  to  be  released  by  the  module.  This  capability  may  be  used  in  bus  diag¬ 
nostics  and  fault  isolation.  In  addition,  no  signal  line  shall  be  asserted 
from  the  time  power  is  applied  to  the  Pi-bus  module  until  the  module  has  com¬ 
pleted  reset  as  defined  in  "5.3.8  Initialization.."  Modules  shall'not  assert 
any  signal  line  in  violation  of  this  specification  during  power  failutj. 
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Table  4-1.  Pi-bus  Signal  Lina  Requirements  By  Type  And  Class 


NAME 


Data  (D3 
D<31 . .  16> 

D<15 . . 0> 

Data  Check  (DC) 

DC<7 . . 2> 

DC<1> 

DC<0> 

Cycle  Type  (CT) 

CT<2 - . 0> 

CT  Check  CCTC) 

CTC<2 , 1> 

ctc<q> 

Acknowledge  Set  (AS) 
AS<5»4> 

AS<3 . . 0> 

Wait  (W) 

W<2> 

U<1 ,  0> 

Bus  Request  (BR) 
BR<2> 

BR<1,0> 


Total  Lines  Required 
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4.2.2. 1  Data  Line  Group  (P//.DCJ. 

The  Data  Croup  shall  consist  of  the  Date  (D)  lines  and  the  Data  Check 
(DC)  lines.  The  Data  Group  is  a  set  of  bi di recti onol  linos  which  shall  trans¬ 
fer  header*  data  and  acknowledge  information  between  the  bus  master  and  the 
slave(s).  The  Data  Group  (D//DC)  lines  shall  also  be  used  to  resolve  priority 
during  a  Vie  sequence. 

4. 2. 2. 1.1  Data  Lines  -  Typo  16. 

Type  16  modules  and  buses  shall  provide  16  Data  lines*  D<15..0>.  DO 
shall  be  the  least  significant  and  D15  the  most  significant  line. 

4. 2. 2. 1.2  Data  Linas  -  Type  32. 

Tyou  32  modules  and  buses  shall  provide  32  Data  lines*  D<31..0>.  DO 
shall  be  the  least  significant  and  DM  the  most  significant  line.  Type  16 
data  transfers  shall  always  use  D<15..0>. 

4.2.2. 1.3  Error  Protection  for  the  Data  Line  Group. 

The  Data  Lino  Group  shall  use  even  parity  for  Class  ED  operation  and  a 
modified  Hamming  Code  fo1-  Class  EC  operation  when  there  is  a  single  source  for 
the  signals.  When  there  may  be  multiple  sources  for  the  signals*  ar*  dur  ing 
vie  cycles  end  during  multiple-slave  acknowledges,  the  Data  Lino  Group  shall 
use  duplication  for  Class  ED  operation  and  triplication  for  Class  EC 
operat i on . 

4 . 2 . 2 . 1 . 3 - 1  Class  ED  Operation* 

4 . 2 . ? . 1 . 3 . 1 . 1  Single  Source.  During  bus  cycles  in  which  a  single  source  is 
specified  for  the  Data  lines,  valid  symbols  for  the  Data  Line  Group  shell  have 
even  pari ty . 

4 .2 . 2 . 1 . 3 . 1 . 1 . 1  Type  16.  The  module  that  sources  the  Data  lines  shall  also 
Sour  ce  trie  Data  Check  line  such  that  the  pel  of  ayinuul:  Oil  D'.lu.  .v^//DC'u> 
satisfies  P( D<15. . 0>//DC<0> )  =  0. 

4 . 2 . 2 . 1 . 3 . 1 . 1 . 2  Type  32.  The  module  that  sources  tha  Data  lines  shall  also 
source  the  Data  Check  lines  such  that  the  set  of  symbols  on  D<1 5  ,..((>/ /DC<  0  > 
satisfies  P( D< 15 . . 0>//DC<0> )  =  0  and  D<31 . . 16>//DC<1>  satisfies 
P(D<31..16/^DC<1>)  =  0. 

4 . 2 . 2 . 1 . 3 . 1 . 2  Multiple  Sources.  During  Vie  and  Multiple  SIav»>  Acknowledge 
Cycles,  the  Data  and  Data  Check  lines  may  have  multiple  sources.  For  those 
operations,  modules  shall  post  duplicate  copies  of  the  required  symbols  using 
Data  lines  D<15..8>  and  D<7..0>  as  duplicate  line  st’:s. 

Usage  of  the  Data  lines  for  Via  and  Multiple  Slave  Acknowledge  Cycles  is 
specified  in  "5.3. 3.1  Vie  Sequence."  and  "5. 2. 3. 3. 2  Multiple  Slave  Acknowl¬ 
edge.,"  respectively. 
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4. 2. 2. 1.5. 2  fil.aaa.ec  QperM Uru 

4. 2. 2. 1.3. 2.1  Single  Source.  During  bus  cycles  in  which  a  single  source  is 
specified  for  the  Data  lines<  valid  symbols  for  the  Data  Line  Group  shall  use 
modified  Hamming  encoding  as  specified  below. 

4 .2 . 2. 1 . 3 . 2 . 1 . 1  Type  16.  The  module  that  sources  the  Data  lines  shall  also 
source  the  Data  Check  lines  such  that  the  set  of  symbols  on  D<15 . . 0>//DC<5 . . 0> 
satisfies: 


PC  DC<5>»  D<  15,14, 13, 12, 11, 10,9, 8>  >  =  0 
P(  DC<4>,  D<15,14,7,6,5,4,3,2>  )  =  0 
PC  DC<3>»  D<  13, 12, 11, 7, 6, 5, 1,0  )  =  0 
PC  DC<2>,  D<15, 13,10,9,7,4,3,0  )  =  0 
PC  DC<1>,  D<12, 10,8,6,4,2,1,0  )  =  0 
PC  DC<0>,  D<14,11,9,8,5,3,2,1>  )  -  0 


4. 2. 2. 1.3. 2. 1.2  Type  32.  The  module  that  sources  the  Data  lines  shall  also 
source  the  Data  Check  lines  such  that  the  set  of  symbols  on 
D<31 . . 16>//DC<6 . . 0>  satisfies: 


PC  DC<6> ,  D<31, 30, 29, 28, 27, 26, 25, 24, 23, 22, 20, 19, 17, 16>  )  =  0 

PC  DC<5>,  D<31. 30, 29, 28, 27, 15, 14, 13, 12, 11, 10, 9, 8>  )  =  0 

PC  DC<4> »  D< 31, 26, 25, 24, 23, 15, 14, 7, 6, 5, 4, 3, 2>  )  =  0 

PC  DC<3>»  D< 30, 26, 22, 21, 20, 19, 13, 12, 11, 7, 6, 5, 1,0>  )  =  0 

PC  DC<2> ,  D<29, 25, 22, 21, lo, 17, 15, 13, 16, 9, 7, 4, 3, 0>  j  -  0 

PC  r<C<l>.  D<28,24,20,18,17,16,12,10,8,6,4,2,1,0>  )  =  0 

PC  DC<0>,  D<27, 23, 21, 19, 18, 16, 14, 11, 9, 8, 5, 3, 2, l>  )  =  0 

4 . 2 . 2 . 1 , 3 . 2 . 2  Multiple  Sources.  During  Vie  and  Multiple  Slave  Acknowledge 
Cycles  the  Data  and  Data  Check  lines  may  have  multiple  sources.  For  those 
operations,  modules  shall  post  triplicate  copies  of  lh«  required  symbols  using 
D<15..8>,  D<7.,0>  and  DC<7..0>  as  triplicate  line  sets. 

Usage  of  the  Data  lines  for  Vie  and  Multiple  Slave  Acknowledge  Cycles  is 
specified  in  ”5. 3. 3.1  Vie  Sequence."  and  "5.2. 3. 3. 2  Multiple  Slave  Acknowl¬ 
edge.,"  respectively. 
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4. 2. 2. 2  Cycle  Type  line  Group  (.CT//CTO. 

The  Cycle  Type  Group  shall  consist  of  the  Cycle  Type  (CT)  and  Cycle  Type 
Check  (CTO  linos.  The  Cycle  Type  Group  is  a  set  of  lines  onto  which  the  bus 
toaster  shall  post  symbols  to  indicate  the  current  bus  cycle  type.  The  bus 
Cycle  Types  shall  be  encoded  as  shown  in  Table  4-2. 


Table  4-2.  Pi-bus  Cycle  Types  and  Valid  Symbols 


Class  ED  Symbol 


Cycle  Type  jAbbreviation 


Abort 

Acknowledge 

Data 

Header  0 

Header 

Idle 

Suspend 

Vie 


Class 
CT<2 . . 0> 

EC  Symbol 
CTC<2 .  .  0  > 

111 

001 

Oil 

110 

001 

Oil 

101 

100 

010 

101 

000 

ooo 

110 

010 

100 

111 

4.  2.2. 3 


The  Acknowledge  Set  is  a  group  of  lines  onto  which  the  slave(s)  or  con¬ 
tenders  shall  post  symbols  to  indicate  synchron i za t i on  or  to  signal  uncorrec- 
table  detected  errors.  Valid  symbols  for  the  Acknowledge  Set  shall  be  as 
defined  in  Table  4-3. 
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Table  4-3.  Acknowledge  Lina  Valid  Symbols 


Response 

Abbreviation 

Class 

AS<3,2> 

ED  Code 
AS<1 » 0> 

Class  EC  Code 
AS<5,4>  AS<3,2>  AS<1,0> 

Acknowledge 

ACK 

10 

10 

10  10 

10 

Negative  Ack 

NAK 

11 

11 

11  11 

11 

Not  Selected 

NS 

00 

00 

00  00 

00 

Recogni ze 

RCG 

— 

01 

01 

01  01 

01 

4. 2. 2. 4  Wait  (M)  l i nes . 

The  Wait  lines  shall  ba  a  sat  of  redundant  lines  which  tha  current  bus 
master  and  slava(s)  may  assert  to  obtain  extra  non-transfer  bus  cycles  to  sup¬ 
ply  information  to  tha  bus  or  to  accept  information  from  the  bus. 

4. 2. 2. 4.1  Class  ED. 

Class  ED  modules  and  buses  shall  provide  two  Wait  lines*  W<1,0>,  that 
shall  operate  as  redundant  Linas.  Valid  symbols  for  this  case  shall  be  W<1,0> 
=  00*  no  wait  request,  and  W<1*0>  -  11*  wait  requested. 

4. 2. 2. 4. 2  Class  EC. 

Class  EC  modules  and  buses  shall  provide  three  Wait  lines,  W<2..0>,  that 
shall  operate  as  redundant  lines.  Valid  symbols  for  this  case  shall  be 
W<2.,0>  =  000  ,  no  wait  request,  and  W<2..0>  =  111,  wait  requested. 

4 . 7. .  2 . 5  Pus  Request  tBR7  lines. 

The  Bus  Request  lines  shall  consist  of  a  set  of  redundant  lines  which 
shall  be  asserted  to  request  that  the  current  bus  master  release  the  bus. 

4. 2. 2. 5.1  Class  ED. 

Class  ED  modules  and  buses  shall  provide  two  Bus  Request  lines,  BR<1,0>, 
that  shall  operate  as  redundant  lines.  Valid  symbols  for  this  case  shall  be 
BR<!,0>  =  00,  no  bus  request,  and  BR<1»0>  =  11,  bus  requested. 
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*.2.2. 5. 2  Class  EC. 

Class  EC  modules  and  buses  shall  provide  three  Bus  Request  lines. 
BR<2..0>,  that  shall  operate  as  redundant  lines.  Valid  symbols  for  this  case 
shall  be  BR<2..0>  =  000.  no  bus  request,  and  BR<2..0>  =  111.  bus  requested. 

*.2.3  BUS  CLOCK. 

Bus  Clock  shall  be  a  single  phase  clock.  All  bus  timing  shall  be  refer¬ 
enced  to  the  high-to-low  transition  of  the  bus  clock.  The  generation  and  dis¬ 
tribution  of  Bus  Clock  is  beyond  the  scope  of  this  specification.  However, 
the  period  of  Bus  Clock  shall  be  selected  to  guarantee  that  bus  timing  con¬ 
straints  are  satisfied  for  the  bus  delays  and  clock  skews  resulting  from  the 
backplane  design. 

4.2.*  MODULE  IDENTIFICATION. 

Pi-bus  modules  shall  have  inputs  for  a  set  of  lines  that  shall  be  hard¬ 
wired  on  the  Pi-bus  backplane  to  provide  a  unique  module  identification. 


The  set  of  5  Module  Identification  (MID)  lines  shall  be  hardwired  on  the 
bockplane  and  shall  be  used  by  the  module  as  the  module's  physical  identifica¬ 
tion  code,  The  identification  codes  shall  consist  of  an  unsigned  binary  num¬ 
ber  in  the  range  of  0-31,  inclusive,  encoded  in  MID<*..0>. 

*.2.4.2  Module  Identification  Parity  Line, 

A  Module  Identification  Parity  (MIP)  line  shall  be  hardwired  on  the 
backplane  such  that  MID<* . . 0>//MIP<0>  satisfies  P (MID<* . . 0 >/^MlP<0> )  =  1. 
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4.3  FLECTR1CAL  REQUIREMENTS 

Electrical  characteristics  for  the  Pi-bus  backplane  and  modulos  shall  bo 
as  specified  herein. 

4.3.1  BACKPLANE  REQUIREMENTS. 

4. 3. 1.1  Bus  Signal  Line  Character i at i c  Impedance. 

PI~Bus  signal  lines  shall  have  a  characteristic  impedance  of  not  less 
than  20  ohms  and  not  more  than  50  ohms  for  all  operating  and  module  loading 
conditions. 

4. 3. 1. 2  Bus  Signal  Line  Termination. 

Signal  lines  shall  be  terminated  at  each  end  of  the  backplane  to  a  cir — 
cuit  which  is  the  Theven i n-equ i va lent  of  a  terminating  resistor  in  series  with 
a  voltaga  source  of  not  less  than  41.9  Volts  nor  more  than  +2.1  Volts.  The 
value  of  the  terminating  resistance  shall  be  between  30  and  40  ohms, 
i nclusi ve. 


4 . 3 . 1 . 3  Bus  Hanoi  lins  Resistance. 

The  series  resistance  for  backplane  signal  lines  shall  be  limited  such 
that  the  maximum  voltage  rise  from  any  asserted  module  output  to  the  terminat¬ 
ing  resistance  at  either  Qnd  of  the  backplane  is  less  than  100  millivolts. 

4 . 3 . 1 . 4  Module  Identification  line  Resistance. 

The  resistance  of  the  grounded  MID  and  MIP  lines  with  respect  to  the  sig¬ 
nal  ground  shall  be  less  than  10  ohms. 

4 . 3 . 1 . 5  Bys  Clock  Requirements. 

4. 3. 1.5.1  Voltaga  Levels. 

The  low  level  voltage  for  Bus  Clock  shall  be  less  than  or  equal  to  +0.55 
volts,  The  high  level  voltage  for  Bus  Clock  shall  ba  greater  than  or  equal  to 
♦2.4  volts. 

4. 3. 1.5. 2  Rise  And  Fall  Tima. 

The  rise  time  (Tr)  of  the  Bus  Clock  from  0.8  volts  to  2.0  volts  shall  be 
less  than  5  nanoseconas.  The  fall  time  (Tf)  of  the  Bus  Clock  from  2.0  volts  to 
0.B  volts  shall  be  less  than  5  nanoseconds. 

4. 3. 1.5. 3  Duty  Cycle. 

The  ratio  of  the  Bus  Clock  high  state  duration  to  the  bus  clock  period 
measured  et  1.5  Volts  shall  not  be  less  than  0.45  nor  greater  than  0.55. 
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Bus  Clock  capacitance  to  logic  ground  shall 


4.3.2  MODULE  REQUIREMENTS. 

4. 3. 2.1  Bus  Clock  Regu-iremej 

4.3. 2. 1.1  DC  Requi rements . 

4. 3. 2. 1.1.1  Input  Capacitor 
be  lass  than  22  picofarads. 

4 . 3 . 2 . 1 . 1 . 2  Input  Inductanc 


4. 3. 2. 1.1.2  Input  Inductance.  Bus  Clock  series  inductance  from  the  module 
input  to  the  receiver  of  the  signal  shall  be  less  than  2?  nanohenries. 

4. 3. 2. 1.1.3  Bus  Clock  Current.  Tho  maximum  current  sourced  by  the  module 
when  the  clock  input  voltage  is  +0.55  volts  shall  be  1.4  mi  11 i amps .  The  maxi¬ 
mum  current  into  the  module  when  the  Bus  Clock  voltage  is  +2.4  volts  shall  be 
less  than  100  microamps. 

4. 3. 2- 1.1,4  High-level  Input  Voltage.  An  Bus  Clock  input  voltage  of  +2.0 
volts  or  more  shall  bo  interpreted  as  a  high  level. 

4. 3. 2. 1.1. 5  low-level  Input  Voltage.  A  Bus  Clock  input  voltage  of  +0.8 
volts  or  less  shall  be  interpreted  as  a  low  level. 

4. 3. 2. 1.2  AC  Requi rements. 

Modules  shall  operate  correctly  with  the  Bus  Clock  characteristics  spec¬ 
ified  in  "4. 3, 1.5  Bus  Clock  Requirements. 

The  maximum  Bus  Clock  frequency  for  the  module  shall  be  specified.  The 
minimum  Bus  Clock  frequency  shall  be  zero  Hertz. 

All  Pi-bus  timing  shall  be  referenced  to  the  high“to_low  transition  of 
Bus  Clock  through  a  voltage  of  1.5  volts. 

4 . 3 . 2 . 2  Signal  Line  Requirements. 

4. 3. 2. 2.1  DC  Requi ramants. 

4. 3. 2. 2. 1.1  Input  Capacitance.  Signal  line  capacitance  to  logic  ground 
shall  be  less  than  22  picofarads. 


4. 3. 2. 2. 1.2  Input  Inductance.  Signal  line  series  inductance  from  the  module 
input  to  the  driver  or  receiver  of  the  signal  shall  be  less  than  27  nanohen- 


4. 3. 2. 2. 1.3  Leakage  Current.  Ovor  the  input  voltage  range  of  +0.3  volts  to 
+  2.1  volts>  the  absolute  value  of  the  output  current  for  any  signal  lino  which 
is  not  being  asserted  by  the  module  shall  be  less  than  100  microamps. 
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4. 3.  2.  2.1.4  |,ou-level  Sink  Current.  Tha  low-level  output  sink  currant  (Iol) 
drive  capability  for  signal  lines  shall  be  greater  then  95  milliemps  at  an 
output  voltage  of  1.15  volts. 

4. 3. 2. 2. 1.5  High-level  Output  Voltage.  The  high-level  output  voltage  shall 
be  determined  by  the  backplane  signal  line  termination  voltage  which  is  +1.9 
to  +2.1  volts.  The  signal  line  outputs  shall  permit  wired-OR  operations  on 
the  bus. 

4. 3. 2. 2. 1.6  low-level  Output  Voltage.  The  low-level  output  voltage  (Vol) 
for  signal  lines  shall  be  less  than  1.15  volts  at  an  input  current  of  95  mil- 
1 i amps. 

4. 3. 2. 2. 1.7  High-level  Input  Voltage.  A  signal  line  input  voltage  (Vih)  of 
+1.6  volts  or  more  shall  be  interpreted  as  a  logic  0.  A  signal  line  input 
which  is  not  electrically  connected  to  the  backplane  (i.e.  an  open  line)  shall 
be  interpreted  as  a  logic  0. 

4. 3. 2. 2. 1.8  low-level  Input  Voltage.  A  signal  line  input  voltage  (Vil)  of 
+  1.45  volts  or  less  ..hall  be  interpreted  as  a  logic  1. 

4. 3. 2* 2. 2  AC  Requirements. 

4. 3. 2. 2. 2.1  Signal  Line  Inputs.  Figure  4-1  illustrates  the  timing 
relationships  specified  below. 

4 . 3.2.2. 2 . 1 . 1  Set-up  Time.  The  maximum  time  that  each  input  signal  is 
required  to  be  uniquely  above  or  below  the  input  voltage  threshold  for  a  logic 
0  or  logic  1  prior  to  the  high-to-low  transition  of  the  clock  (set-up  time* 
Ts)  shall  be  specified. 

4 . 3 . 2 . 2 . 2 . 1 . 2  Hold-Time.  The  maximum  time  that  each  input  signal  is 
required  to  be  uniquely  above  or  below  the  input  voltage  threshold  for  a  logic 
0  or  logic  1  following  the  high-to-low  transition  of  the  clock  (hold  time*  Th> 
shall  be  specified  and  shall  not  exceed  the  minimum  propagation  delay  time  of 
the  module. 

4. 3. Z-2. 2.1. 3  noise  Rejection.  The  input  signal  lines  shall  reject  and  the 
Bus  Interface  shall  not  respond  to  any  signal  pulse  whose  width  as  measured 
between  1.5  volts  on  the  low-to-high  transition  and  1.5  volts  on  the 
high-to-low  transition  is  less  than  4  nanoseconds. 

4. 3. 2. 2. 2. 2  Signal  line  Outputs.  The  following  specifications  shall  apply 
when  the  signal  line  is  connected  to  the  test  circuit  of  Figure  4-2. 

4 . 3 . 2 • 2 .2 . 2 . 1  Propagation  Delay.  Propagation  delay  shall  be  measured  with 
respect  to  the  high-to-low  transition  of  Bus  Clock  as  illustrated  in 
Figure  4-3.  The  reference  clock  voltage  for  timing  shall  be  +1.5  volts.  The 
reference  signal  voltage  for  timing  shall  be  +1.5  volts. 

The  minimum  and  the  maximum  propagation  delay  (Tpdlh)  for  an  output  »ig- 
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nal  changing  from  a  logic  1  (low  voltage)  to  a  logic  0  (high  voltage)  shall  be 
specified  for  each  output  signal  line. 

The  minimum  and  the  maximum  propagation  delay  (Tpdhl)  for  an  output  sig¬ 
nal  changing  from  a  logic  0  (high  voltage)  to  a  logic  1  (low  voltage)  shall  be 
specified  for  each  output  signal  line. 

4. 3. 2. 2. 2. 2.2  Rise  And  Fell  Time.  The  rise  time  (Tr)  of  an  output  signal 
from  *1.2  volts  to  *1.8  volts  shall  be  less  than  9  nanoseconds.  The  fall  time 
(Tf)  of  an  output  signal  from  *1.8  volts  to  *1.2  volts  shall  be  less  than  9 
nanoseconds. 

4. 3. 2. 3  HID  And  MIP  lines. 


A  binary  1  shall  be  represented  by  a  connection  to  signal  ground  and  a 
binary  0  shall  be  represented  by  an  open  circuit.  Modules  shall  incorporate 
any  circuits  they  require  to  sense  the  MID  and  MIP  lines.  The  absolute  cur¬ 
rent  into  a  grounded  MID  or  MIP  line  shall  be  less  than  1  milliamp.  The  maxi¬ 
mum  voltage  that  shall  exist  on  an  open  MID  or  MIP  line  shall  not  exceed  25 
volts. 


CLOCK  INPUT 


■-  1.5v 


DATA  INPUT 


Figure  4-1.  Set-up  And  Hold  Timing 
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•INCLUDES  JIG  AND  PROBE  CAPACITANCE 

Figure  4-2-  Signal  Output  Test  Circuit 
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Section  5 


DATA  LINK  LAYER 


The  Data  Link  layer  of  the  Pi-bus  is  specified  herein.  The  general  pro¬ 
tocol  used  by  the  Pi-bus  is  defined  through  specification  of  the  protocol 
state  transitions  and  the  generic  message  sequence.  Detailed  requirements  for 
the  protocol  and  communications  sequences  are  specified  by  defining  each 
sequence  and  the  rules  associated  with  the  Pi-bus  protocol.  Responses  to 
exception  conditions  are  defined. 


5.2.1  INTRODUCTION. 

The  Pi-bus  uses  a  master-slave  protocol  under  which  communications 
sequences  are  defined  for  1)  transferring  messages  between  modules  and  2) 
changing  bus  mastership.  The  I  1  bus  communications  sequences  are  listed  in 
Table  5-1.  The  Vie  sequence  shall  be  performed  only  when  there  is  no  current 
bus  master.  All  other  sequences  shall  be  performed  under  the  control  of  the 
current  bus  master. 

The  Pi-bus  uses  a  set  of  protocol  statu  transitions  to  define  and  con¬ 
trol  the  communication  sequences.  Protocol  stato  transitions  shall  be  sig¬ 
naled  on  the  Cycle  Tyoe  (CT)  lii.^j  and  shall  be  controlled  by  the  bus  master. 
The  slave(s)  shall  operate  in  synchronization  with  the  bus  master  and  shall 
signal  compliance  with  protocol  state  transitions  using  the  Acknowledge  Set 
(AS)  lines.  Slave(s)  shall  also  use  the  AS  lines  to  notify  the  bus  master  of 
any  uncorrectable  errors  that  are  detected. 

The  seven  sequence  states  defined  for  v;he  Pi-bus  protocol  are  summarized 
in  Table  5-2.  Within  each  sequence  state?  bus  states  are  defined  to  distin¬ 
guish  individual  bus  cycles.  The  specific  sequences  of  bus  states  required  to 

_ _  is  t _ i _ _  _ .■ _ i.  ! _ _  _  _ i  _ i _  flc  i  hCT  1  T  i  Cn 

|/«ci  i  ui  m  i  wvminuiii  v?0UUH3  fir  «  uf  >  i  iiku  uiiuhi  j  •  j  vuiului/ 

REQUIREMENTS.."  In  this  section,  general  requirements  for  the  overall  opera¬ 
tion  of  the  Pi-bus  ere  specified  by  reference  to  the  sequence  states  and  the 
generic  message  protocol  they  support. 
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Table  5-1. 

Pl-bua  Communications  Sequences 

Sequence  Type 

Function 

Mastership  Sequences: 

Vie 

Assigns  bus  mastership  to  the  highest 
priority  module  contending  for 
mastership  through  arbitration. 

Tenure  Pass  Massage 

Transfers  bus  mastership  from  current 
bus  master  to  another  module  or  changes 
the  bus  master's  message  priority. 

Message  Sequences: 

Parameter  Urite 

Transfers  a  1  word  parameter  and  a 

32  bit  address  from  the  bus  master 
device  to  the  slave  devicats). 

Block  Message 

Transfers  up  to  65.536  datum  units  from 
slave  device  to  master  device  or  from 
master  device  to  slave(s).  Master  sends 
a  32  bit  address  and  may  send  6  other 

Header  words.  May  be  used  to  continue  a 
suspended  message. 

Bus  Interface  Messagn 

Transfers  up  to  256  words  from  slave  bus 
interface  to  the  master  device  or  from 
master  device  to  slave  Bus  Interfaced). 
Master  provides  an  8  bit  address. 

Exception  Sequences: 

Suspend 

Suspends  a  Biock  Message  data  sequence 
and  transfers  Resume  Control  Words  from 
the  sieve  tc  the  master. 

Abort 

Abnormally  terminates  current  sequence. 
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Table  5-2 

Protocol  State 

Idle 

Vie 

Header 

Header  Acknowledge 
(Header  Ack) 

Data 

Data  Acknowledge 
(Data  Ack) 

Abort 


Pi-bus  Protocol  States 

Function 


Bus  not  in  use  and  no  current  bus  waster 
defined. 

State  following  Idle.  Used  to  select 
the  next  bus  waster  from  one  or  more 
contending  modules-  The  module  with 
the  highest  priority  is  selected  as 
t.ho  next  bus  master  . 

State  in  which  information  is 
transmitted  by  the  master  to  specify 
the  type  of  message  sequence,  identify 
modules  to  participate  as  slaves  and 
specify  additional  application  dependent 
i  nf  orwiet  i  on  . 

State  following  Header  during  which 
slave  module(s)  provide  sequence  status 
information  to  the  master. 

State  during  which  data  are  transferred 
between  th&  slave  module(s)  and  the 
master  for  Block  Messages  and  Bus 
Interface  Messages. 

Block  Message  Suspend  sequences  ore 
performed  under  this  protocol  state. 

State  following  Data  during  which 
slave  module(s)  provide  message  .status 
information  to  the  master. 

State  used  to  abnormally  terminate 
another  bus  sequence. 
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5.2.2  PROTOCOL  STATE  TRANSITIONS. 

The  protocol  states  which  shall  be  used  in  Pi-bus  operations  are  illus¬ 
trated  in  Figure  5-1.  All  state  transitions  shall  occur  on  the  high-to-low 
transition  of  Bus  Clock.  The  allowable  transitions  between  protocol  states 
are  specified  in  the  sections  below  and  in  Figure  5-1. 

5.2.2. 1  Idle. 

The  bus  shall  enter  the  Idle  state  whenever  all  Cycle  Type  lines  are 
released.  There  shall  be  no  bus  master  during  Idle  and  the  current  bus  master 
priority  code  shall  be  undefined.  Idle  shall  consist  of  two  or  more  consec¬ 
utive  bus  cycles  in  which  the  Cycle  Type  lines  are  released.  No  Pl-bus  oper¬ 
ations  shall  be  performed  during  Idle  except  that  the  symbol  NAK  (Negative 
Acknowledgement)  may  be  posted  on  the  AS  lines  as  specified  in  "5 . 2 . 3 . 1 . 2 . 2 
Uncorrectable  Errors."  Vie  shall  be  the  only  valid  successor  state  to  Idle. 
The  Idle  state  shall  be  terminated  and  the  Vie  state  entered  only  when  one  or 
more  modules  post  the  symbol  V  on  the  Cycle  Type  lines. 

5. 2. 2. 2  Xjju 

The  Vie  state  shall  consist  of  eight  bus  cycles  which  shall  be  used  to 
select  the  next  bus  master  from  one  or  more  contenders.  The  Vie  state  shall  be 
succeeded  by  the  Header  state  except  that  if  no  bus  master  is  selected  due  to 
erroneous  operation,  the  bus  shall  return  to  the  Idle  state. 

5.2.2. 3  Header . 


A  bus  master’s  tenure  shall  begin  when  the  Header  state  is  entered  from 
the  Via  state  or  from  the  Header  Acknowledge  state  of  the  Tenure  Pass  message. 
The  current  bus  master's  tenure  shall  continue  when  the  Header  state  is 
entered  from  the  Header  Acknowledge  state  of  the  Parameter  Write  sequence, 
from  the  Data  Acknowledge  state  or  from  the  Abort  scate.  During  the  Header 
state,  the  bus  master  shall  transmit  header  information  across  the  bus  on  two 
or  more  bus  cycles. 

TKo  MfiaHor  ftku  1  1  e  nnr  i  4-kr*  4 winK  c  »rin  Bnmmnrn  4-  n  ka  nn»*  4n  •‘Munrl 

identify  the  modules  required  to  participate  in  the  sequence  as  slaves  and 
define  tho  number  of  data  transfer  cycles  required  for  the  sequence.  Tho  Head¬ 
er  state  shall  be  succeeded  by  the  Header  Acknowledge  state  except  that  Abort 
may  be  entered  to  terminate  the  sequence. 

5 . 2 . 2 . 4  Header  Acknowledge. 

The  Header  Acknowledge  state  shall  be  used  to  transmit  message  status 

from  the  slave  module(s)  to  the  master.  The  transitions  out  of  the  Header 

Acknowledge  state  shall  be  as  specified  below: 

1.  For  «  Parameter  Write  message  sequence,  the  auccessor  states  to  Header 

Acknowledge  shall  be  Header,  Idle  and  Abort.  A  transition  to  Header 

shall  initiate  a  new  message  and  extend  the  the  current  bus  master's  ten- 
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ura.  A  transition  to  Idle  shall  terminate  the  current  bus  master's  ten¬ 
ure.  Abort  may  be  entered  to  terminate  the  Parameter  Write  message. 

2.  For  Block  Message  and  Bus  Interface  Message  sequences,  the  successor 
states  to  Header  Acknowledge  shall  be  Data  and  Abort.  A  transition  to 
Data  continues  the  current  bus  master's  tenure.  Abort  may  be  entered  to 
terminate  the  message. 

5.  For  a  Tenure  Pass  Message  sequence,  the  successor  states  shall  be  Header 
or  Abort  except  that  when  the  intended  next  bus  master  does  not  require 
or  fails  to  acquire  bus  mastership,  the  successor  state  shall  be  Idle. 
The  current  bus  master's  tenure  shall  end  at  the  conclusion  of  a  Tenure 
Pass  Message  Header  Acknowledge  (HAZ)  end  the  new  bus  master's  tenure 
shall  begin  on  the  next  cycle  with  entry  into  the  Header  state.  Abort 
may  be  entered  from  a  Tenure  Pass  Message  except  on  the  last  cycle  (cycle 
HAZ)  of  the  message. 

5. 2. 2. 5  Data  . 

The  Data  state  shall  consist  of  a  sequence  of  Data  transfer  cycles  pet — 
formed  as  part  of  a  Block  Message  or  Bus  Interface  Message.  Data  may  be  trens- 
!  ferred  from  the  master  to  the  slave(s).  defined  as  a  write  sequence,  or  from 
I  the  slave  to  the  master,  defined  as  a  read  sequence.  For  Block  Message 
1  sequences  only,  the  Data  sequence  may  be  suspended  by  entry  into  the  Suspend 
state.  Unless  a  Data  sequence  is  suspended  or  terminated  by  entering  Abort, 
the  successor  state  to  Data  shall  be  Data  Acknowledge. 

5. 2. 2. 6  Suspend . 

I  The  Suspend  state  shall  be  used  to  signal  the  pending  interruption  of  a 

I  Block  Message  Data  sequence  as  specified  in  the  detailed  requirements  (see 
"5. 3. 5.1  Suspend.").  A  suspended  Block  Message  Date  sequence  can  be  resumed 
by  another  Block  Message  whose  header  contains  the  appropriate  Resume  Control 
Words.  The  successor  state  to  Suspend  shall  be  Data  Acknowledge  except  that 
the  sequence  may  be  terminated  by  entering  Abort, 

5. 2. 2. 7  Data  Acknowledge. 

The  Data  Acknowledge  state  shall  be  used  to  transfer  acknowledge  infor¬ 
mation  from  the  slave(s)  to  the  master  during  a  Block  Message  or  Bus  Interface 
Message  sequence.  The  successor  states  to  Data  Acknowledge  are  Header,  Idle 
and  Abort.  A  transition  to  Header  shall  initiate  a  new  message  end  extend  the 
the  current  bus  master's  tenure.  A  transition  to  Idle  shall  terminate  the 
current  bus  master's  tenure.  Abort  may  be  entered  to  terminate  a  message. 

5. 2. 2. 8  Abort . 

The  Abort  state  shall  consist  of  four  consecutive  bus  cycles  in  which 
the  Abort  cycle  type  is  posted  on  the  CT  lines.  The  successor  states  to  Abort 
shall  be  Header  and  Idle.  A  transition  to  Header  shall  initiate  a  new  message 
and  extend  the  the  current  bus  master's  tenure.  A  transition  to  Idle  shall 
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terminate  the  current  bus  master's  tenure. 

5.2.2. 9  Tenure  L imi tat i png, 

5. 2. 2. 9.1  Bus  Request  To  Vie  Interval. 

When  Bus  Request  is  asserted,  the  bus  master  shall  limit  the  number  of 
bus  cycles  remaining  in  the  current  tenure  to  the  sum  of  the  bus  cycles  speci¬ 
fied  by  the  contents  of  the  Vie  Interval  A  Register  plus  the  contents  of  the 
Vie  Interval  5  Register  plus  six  cycles  <see  "5. 3. 7. 3. 9  Vie  Interval  A  Regis¬ 
ter  -  Address  3."  and  "5. 3. 7. 3. 5  Vie  Interval  B  Register  -  Address  4."). 
Section  "5. 3. 3-3  Bus  Request."  specifies  procedures  which  the  bus  master 
shall  use  to  relinquish  tenure  and  permit  a  Vie  sequence  in  response  to  Bus 
Request. 

5.2.2. 9.2  Absolute  Tenure  Limit. 

Pi-bus  modules  shall  internally  limit  each  of  their  individual  tenures  as 
bus  master  to  a  maximum  of  (2KX241+8  bus  cyclos.  The  cycle  count  shall  begin 
with  the  first  HO  cycle  of  the  master's  tenure  end  shall  include  all  bus 
cycles  (including  non-transfer  cycles).  Each  modulo  shall  provide  a  hardwired 
mechanism  to  automatically  forea  all  signal  outputs  from  the  modulo  to  end 
tenure  such  that  this  tenure  limit  is  not  exceeded.  The  module  may  resume 
normal  operation,  including  vying  for  the  bus,  after  allowing  the  bus  to  be  in 
tiie  Idle  state  for  a  minimum  of  two  cyclrs. 
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KEY: 

EOM  •  END  OF  MESSAGE 
EOT -END  OF  TENURE 
ACK  -ACKNOWLEDGE 


INTRA  i  LNUKt  i  riAiySi  i  iuNb 


INTER  TENURE  TRANSITIONS 

- ► 


EXEPTION  TRANSITIONS 


BLOCK  MESSAGE 

BUS  INTERFACE  MESSAGE 


BLOCK  MESSAGE 

BUS  INTERFACE  MESSAGE 


Figure  5**1.  Pi-bus  Protocol  State  Diagram 
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5.2. 1  GENERIC  MESSAGE. 

The  generic  message  sequence  that  forms  the  basis  for  the  Pi-bus  message 
sequences  is  described  in  this  section.  The  Vie  sequence  is  specified  in 
"5.3.3  Bus  Mastership."  and  the  exception  sequences  aro  specified  in 
"5.3.5  Exception  Sequences. 

Table  5-3  illustrates  the  penaric  Pi-bus  message  sequence  which  shall  be 
composed  of  Header,  Header  Acknowledge,  Data  end  Data  Acknowledge  sequences 
that  correspond  to  the  protocol  states  described  in  the  preceding  section. 


5.2. 3.1 


5. 2. 3. 1.1  Normal  Operation. 


The  Data  (D)  lines  transfer  information  between  the  master  and  slave 
modules  to  accomplish  the  following: 

1.  signal  the  type  of  message  sequence  to  be  performed; 

2.  establish  a  communications  path  to  the  slave  module(s); 

3.  transfer  data  between  the  master  and  the  slavefs);  and 

•ii.  transfer  acknowledge  information  from  the  slcve(s)  to  the  master. 


The  bus  master  shall  use  Type  3Z  message  sequences  only  when  the  master  and 
all  modules  selected  as  slaves  for  that  sequence  are  operating  as  Type  32  mod¬ 
ules  on  a  Type  32  bus.  For  a  Type  32  bus,  Type  32/Type  16  message  sequence 
selection  can  be  made  on  a  message-by-measege  basis  and  thus  may  vary  during 
the  bus  master’s  tenure. 


The  Cycle  Type  CCT)  and  Acknowledge  Set  CAS)  lines  shall  provide  hand¬ 
shaking  between  the  master  and  slave(s)  to  control  the  sequence  of  bus  states. 
The  AS  lines  shall  also  be  used  by  the  slaveCs)  to  report  errors. 


5. 2. 3. 1.1.1  Header .  The  bus  master  shall  initiate  a  message  sequence  by 
transmitting  Header  information  on  the  D  lines.  The  bus  ii'iastvf  shall  post  the 
symbol  HO  on  the  Cycle  Type  (CT)  lines  during  the  first  bus  cycle  of  Header 
transfer  and  shall  post  H  for  each  of  the  remaining  bus  cycle*  of  header 
transfer . 


The  header  shall  specify  the  moduluCs)  whicl  are  selected  as  slave(s)  for 
I  the  message  sequence.  Active  module(s)  which  ore  addressed  by  the  slave  ID 
I  field  of  HWA  shall  become  slaves  on  the  third  cycle  of  Header  transfer, 

I  Slaves  shall  signal  their  participation  in  the  message  by  posting  the  symbol 
RCG  (Recognize)  on  the  Acknowledge  Set  (AS)  lines  beginning  with  the  third 
I  cycle  of  header  transfer  and  continuing  until  header  tran5fer  is  complete. 

I  Modules  shall  cease  being  slaves  when  the  current  message  is  closed  by  a  nor* 
I  mol  completion.  Abort  or  Suspend.  All  modules  shall  ensure  that  the  AS  lines 
are  released  during  the  first  two  cycles  of  Header  except  that  NAK  shall  b» 
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Table  5-3.  Generic  PZ-bus  Message  Sequence 


PROTOCOL  BUS  STATE 

* 

SIGNAL  LINES 

HEADER 

HEADER 

DATA 

DATA 

ACKNOWLEDGE 

ACKNOWLEDGE 

DATA 

Header 

Acknowledge 

Data 

Acknowledge 

Source= 

Master 

Slave( s) 

Master  (Write) 

SlaveC  a ) 

Slave  (Read) 

CYCLE  TYPE 

HO 

H 

A 

D 

A 

(S) 

Source=Master 

ACKNOWLEDGE 

NS 

NS 

RCG 

ACK 

RCG 

ACK 

Source= 

Slave 

Slave 

Slave 

Slave 

asserted  as  specified  in  *5-2.3. 1.2-2  lincorrectable  Errors"  to  report  errors 
from  the  preceding  Sequence. 

5. 2. 3. 1.1. 2  Header  Acknowledge.  The  Header  Acknowledge  sequence  shall  fol¬ 
low  the  Header  sequence.  A  single  Header  Acknowledge  transfer  cycle  shall  be 
used  for  all  single  slave  sequences.  The  Tenure  Pass  Message  sequence  shall 
include  an  additional  (non-transfer)  cycle  to  ensure  a  proper  transition  of 
mastership.  The  bus  master  shall  post  the  Header  Acknowledge  Cycle  (A)  symbol 
on  the  CT  lines  during  the  Header  Acknowledge  cycle  in  which  the  slave  is 
scheduled  to  post  the  slave  Acknowledge  word.  The  slave  shall  indicate  syn¬ 
chronization  with  the  bus  master  by  posting  ACK  on  the  AS  lines  during  the 
I  Header  Acknowledge  cycle.  five  Header  Acknowledge  transfer  cycles  shall  be 
|  used  for  a  multiple  slave  sequence.  During  the  first  multiple  slave  header 
i  acknowledge  cycle,  all  slaves  post  a  Message  status  symbol  on  the  data  lines 
|  and  the  ACK  symbol  on  the  AS  lines.  During  each  of  the  four  remaining  eckriowl- 
I  edge  cycles,  eight  of  the  thirty-two  modules  are  assigned  a  bit  position  on 
the  data  lines  upon  which  to  post  art  acknowledge  bit  and  shall  indicate  syn¬ 
chronization  with  the  bus  master  by  posting  ACK  ori  the  AS  lines. 

The  Header  Acknowledge  sequence  shell  complete  the  Tenure  Pass  Message 
and  Parameter  Write  Message.  The  Block  Message  and  Bus  Interface  Message 
sequences  shall  continue  with  a  Data  sequence  consisting  of  one  cr  more  data 
transfer  bus  cycles. 


\ 


B-35 


Pi-bus  Specification 


Vnrsi on  2.0 


5. 2. 3. 1.1. 3  Data .  The  bus  master  shall  post  the  symbol  D  during  each  cycle 
of  the  Data  sequence.  The  slave  moduleCs)  shall  post  RCG  during  each  cycle  of 
the  Data  sequence.  The  bus  master  shall  transmit  data  during  write  sequences 
and  the  slave  shall  transmit  data  during  the  read  sequences. 

5. 2.3. 1.1. 4  Data  Acknowledge. .  The  Data  sequence  shall  be  followed  by  a 
Data  Acknowledge  sequence.  The  Data  Acknowledge  sequence  is  identical  in  form 
to  the  Header  Acknowledge  sequence.  Block  Messages  and  Bus  Interfaco  Messages 
shall  be  concluded  at  the  end  of  the  Data  Acknowledge  sequence. 

5. 2. 3. 1.2  Operation  Under  Exception  Conditions. 

5. 2. 3- 1-2-1  Block  Message  Suspend.  The  Data  sequence  of  a  Block  Message  may 
be  suspended  by  the  bus  master  to  permit  higher  priority  communications.  The 
Suspend  sequence  shall  be  performed  as  defined  in  "5. 3.5.1  Suspend.." 

5. 2. 3. 1.2. 2  (Jncorrectable  Errors.  Modules  which  are  slaves  shall  signal 
uncor rectabl e  detected  errors  by  posting  the  symbol  NAK  on  the  AS  lines  end 
providing  ®n  error  log  in  the  Acknowledge  words  as  specified  herein.  Modules 
shall  post  the  symbol  NAK  in  response  to  an  uncorrecteble  error  which  occurs 
during  a  Vie  or  during  a  Tenure  Pass  Message  sequence. 

A  module  that  detects  an  uncorroctable  error  which  applies  to  the  opera¬ 
tion  of  bus  cycle  N  shall  post  the  symbol  NAK  on  bus  cyclQ  N+2,  If  the 
detected  error  occurred  during  the  last  two  cycles  of  a  message,  the  resultant 
NAK  occurs  during  the  first  two  cycles  of  the  following  message  nr  THi d t  Mod¬ 
ules  which  are  not  sieves  nor  contenders  in  a  particular  message  sequence 
shall  not  otherwise  post  NAK  during  that  sequence. 

Slave  modules  shall  record  detected  error  conditions  for  the  current 
message  in  the  single  slave  Acknowledge  word  or  Multicast  Acknowledge  Register 
as  appropriate.  The  Bus  Interface  should  also  notify  the  device  of  any 
detected  errors.  When  an  Acknowledge  Word  is  transmitted  on  the  bus  or  stored 
into  the  Multicast  Acknowledge  Register,  the  error  field  shall  not  include 
errors  which  apply  to  the  immediately  preceding  bus  cycle. 

NAK  shall  have  no  specified  effect  on  the  resulting  operation  of  the 
Pi-bus  other  than  that  when  NAK  occurs  or  the  asserted  state  of  an  Acknowledge 
word  error  bit  is  detected,  the  master  Bus  Interface  should  report  that  fact 
to  the  master  device.  The  protocol  provides  the  Abort  sequence  as  a  means  for 
the  message  to  be  terminated  if  required  by  the  device. 

5 . 2 . 3 . 2  Generic  Header  Definition, 

The  Fl-bus  protocol  defines  message  headers  consisting  of  two  to  ten 
words.  The  first  header  word.  Header  Word  A  (HWA),  shall  be  used  in  all  mes¬ 
sage  sequences  to  define  1)  the  type  of  message  and  2)  the  slave  modules  for 
that  message.  The  number  of  scheduled  cycles  in  a  message  shall  be  defined  by 
the  message  type  and  a  datum  transfer  cycle  count  which  shall  be  given  implic¬ 
itly  in  HWA  or  explicitly  in  the  second  header  word.  Header  Word  B  (HUB).  For 
the  Bus  Interface  Message,  HUB  shall  also  contain  an  eight  bit  virtual  address 
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for  the  Bus  Interface  registers.  The  32  bit  virtual  address  used  in  Block  and 
Parameter  Write  messages  shall  be  contained  in  the  third  and  fourth  header 
words,  Header  Word  CO  (HWCO)  and  Header  Word  Cl  (HWC1).  Block 
Message-extended  header  sequences  provide  six  additional  header  words,  HUDO 
through  HWD5.  for  application  dependent  uses. 

The  generic  format  for  Header  Word  A  (HUA)  is  defined  in  this  section. 
Formats  for  the  remaining  Header  words  are  specific  to  each  message  sequence 
end  are  defined  in  "5.3  DETAILED  REQUIREMENTS.." 

5. 2. 3. 2.1  Header  Word  A. 

The  format  illustrated  in  Figure  5-2  shall  be  used  for  Header  Word  A. 
The  fields  of  HWA  shall  be  as  specified  below. 

5. 2. 3. 2. 1.1  Slave  Identification  (ID)  Field.  The  Slave  ID  field  of  HWA  shall 
specify  the  modules  required  to  participate  in  the  message  sequence  as  slaves. 
The  Slave  ID  field  shall  provide  an  eight  bit  virtual  slave  address.  The  vir¬ 
tual  slave  address  (Slave  ID)  range  shall  be  partitioned  into  32  single  slave 
physical  addresses,  a  slave  broadcast  address  and  223  optional  logical  slave 
addresses.  The  broadcast  Slave  ID  shall  select  all  active  modules  as  slaves, 
including  the  bus  master  module. 

The  logical  Slave  ID’s  shall  be  used  only  to  define  aliases  for  individ¬ 
ual  slave  physical  addresses  or  sets  of  slave  physical  addresses.  The  use  ef 
a  logical  Slave  ID  rather  than  a  physical  Slave  ID  in  addressing  a  module 
shall  not  elicit  any  slave  module  response  other  than  that  which  would  have 
been  produced  by  using  the  module's  physical  Slave  ID.  A  Slave  ID  value  of  0 
to  31  shall  specify  the  single  module  whose  Modulo  Identification  matches  the 
Slave  ID  field.  A  Slave  ID  value  of  32  shall  select  all  active  modules  os 
slaves.  The  Slave  ID  values  33  to  255  shall  select  any  active  modules  with  the 
given  Slave  ID  enabled.  The  number  of  modules  which  respond  to  each  of  the 
logical  Slave  ID  values  33  to  255  is  system  dependent.  This  means  that  Slave 
ID  values  33  -  255  can  be  used  for  single  slave  messages  or  multiple  slave  mes¬ 
sages  depending  on  the  application. 

During  message  sequences  where  the  current  bus  master  module  is  selected 
as  a  slave,  the  modulo  shall  act  as  both  a  master  and  a  slave  to  the  extent 
that  the  complete  standard  bus  massage  sequence  can  be  observed  on  the  bus 
lines. 

5. 2. 3. 2. 1.2  Format  Field  (F).  The  Format  field  shall  specify  whether  the 
message  sequence  will  be  performed  using  16  bit  (Type  16)  transfers  or  32  bit 
(Type  32)  transfers.  The  master  devica  must  insure  that  32  bit  transfers  ere 
used  only  when  no  Type  16  module  is  selected  as  a  sieve. 

5. 2. 3. 2. 1.3  Message  Type  Field  (USD  TYPf).  The  Message  Type  field  shall 
specify  the  type  of  message  sequence  to  be  performed  according  to  the  values 
in  Table  5-A.  The  master  devica  must  ensure  that  only  the  multiple  slave  Mes¬ 
sage  Types  are  used  when  more  than  one  module  is  selected  by  the  Slave  ID 
field. 
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5. 2. 3. 2. 1.4  A&&&5L5  „r.VF.P  .flaljLJALL.  The  Access  Type  (AT)  field  shall  be 
passed  from  the  master  device  to  the  Slav®  module  for  use  as  defined  herein 
and  listed  in  Table  55. 


Application  specific  AT  codes  may  be  used  to  classify  the  type  of  device 
access  to  be  performed  during  «  particular  message.  Typical  uses  are  1)  tn 
specify  direct  or  indirect  addressing,  2)  to  speci fy  address  increments,  3)  to 
specify  device  dependent  interpretations  for  extended  header  words  and  4)  to 
access  specific  processes  in  the  device. 


I  For  Block  Messages,  bit  13  shall  be  used  to  signal  the  device  that  the 

I  current  message  is  a  new  Block  Messages  tbit  13  ~  0)  or  a  resumption  of  a  prnvi  — 
I  ously  suspended  Block  Message  (bit  13  ”•  1). 


For  Bus  Interface  Messages,  the  code  000  shall  be  used  to  access  the 
Data  Link  address  space.  The  Bus  Interface  physical  and  Data  Link  layers 
shall  not  utilize  any  AT  field  information  except  that  contained  in  a  Bus 
Interface  Message.  Codes  001  through  011  shall  be  reserved  for  future  use  by 
higher  level  protocols.  Higher  level  protocols,  such  as  those  which  provide 
communications  between  modules  on  different  backplanes,  are  beyond  the  scope 
of  this  specification. 


Reserved  AT  codes  shall  be  defined  only  by  future  versions  of  this  spec¬ 
if  i  cati  on. 


Figure  5-2.  Header  Word  A  Format  -  Data  Lins'.s 


AT 

MSG  TYPE 

F 

15  14  13 

12  11  10  5 

a 

SLAVE  ID 


!  turn 
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(33  to  255  -  LOGICAL  ID) 
(32  -  BROADCAST  ID) 

(0  to  31  -  PHYSICAL  ID.) 


FORMAT  -  0  =  16  BIT  TRANSFER 
-  1  =  32  KIT  TRAH5FER 


MESSAGE  TYPE  (see  Table  5-4) 
ACCESS  TYPE  (nun  Table  5-5) 
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Table  5-4 


Message  Type  Codas 


SINGLE  OR 

READ 

MESSAGE 

MESSAGE  TYPE 

MULTIPLE 

OR 

TYPE 

CODE 

SLAVES 

WRITE 

HU  A 

<12. .9> 

PARAMETER  WRITE 

SINGLE 

WRITE 

0 

0 

0  1 

MULTIPLE 

WRITE 

0 

0 

1  1 

BLOCK  MESSAGE 

-SHORT  HEADER 

SINGLE 

WRITE 

0 

1 

0  1 

SINGLE 

READ 

0 

1 

0  0 

MULTIPLE 

WRITE 

0 

1 

I  1 

-EXTENDED  HEADER 

SINGLE 

WRITE 

1 

1 

0  1 

SINGLE 

READ 

1 

1 

0  0 

MULTIPLE 

WRITE 

1 

1 

I  1 

TENURE  PASS 

SINGLE 

WRITE 

1 

0 

1  0 

BUS  INTERFACE 

SINGLE 

WRITE 

1 

0 

0  1 

SINGLE 

READ 

1 

0 

0  0 

MULTIPLE 

WRITE 

1 

0 

1  1 

NOTE:  Codes  not  listed  above  are  reserved 
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Table  5-5.  Access  Type  Codas 


SEQUENCE  TYPE  ACCESS  TYPE  CODE 

HWA  <15 . .  13> 


PARAMETER  WRITE 

000 

THRU 

110 

' 

APPLICATION  SPECIFIC. 
(PASSED  TO  DEVICE) 

111 

- 

RESERVED. 

BLOCK  MESSAGE 

BITS  15-14 

00 

THRU 

11 

APPLICATION  SPECIFIC 
(PASSED  TO  DEVICE) 

BIT  13 

0 

- 

NEW  MESSAGE 

1 

— 

RESUME  PREVIOUS  MESSAGE 

TENURE  PASS 

000 

- 

TENURE  PASS. 

001 

THRU 

111 

- 

RESERVED. 

BUS  INTERFACE 

000 

- 

BUS  INTERFACE  LINK  REGISTER 
SPACE. 

001 

THRU 

on 

RESERVED  FOR  HIGHER  LEVEL 
PROTOCOL  ACCESS. 

100 

THRU 

110 

"" 

IMPLEMENTATION  DEFINED 
REGISTER  SPACE. 

111 

- 

RESERVED. 

5 . 2 . 3 . 3  Header  And  Data  Sequence  Acknowledgement. 

Haedar  end  Data  Acknowledge  sequences  hove  the  same  form  and  use  the 
soma  word  formats.  There  are  two  basic  formats  for  the  acknowledgement,  sin- 
I  gle  slave  and  multiple  slave.  The  single  slave  Acknowledge  sequence  snali  be 
I  used  when  the  Sequence  Type  field  in  HWA  specifies  a  single  slave  sequence  and 
|  the  multiple  Slave  Acknowledge  sequence  shall  be  used  whenever  the  Sequence 
I  Type  field  in  HWA  specifies  a  multiple  slave  sequence.  The  single  slave 
I  Acknowledge  sequence  transfers  one  word  of  message  status  information  from  the 
I  slave  to  the  master.  The  multiple  slave  Acknowledge  sequence  transfers  1) 
I  eight  bits  of  aggregate  message  status  information  from  the  slaves  to  the  mas- 
I  ter  and  2)  an  individual  bit  of  message  status  information  from  each  of  the  32 
I  possible  slave  devices  to  the  master. 
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3.2.3.3.X  Single  Slava  Acknowledge. 

The  slave  module  shall  perform  error  checking  and  logging  during  the 
message  sequence.  The  Single  Slave  Acknowledge  Word  (AUS)  defined  herein  pro¬ 
vides  the  master  with  a  record  of  the  logged  errors  and  the  Module  Identifica¬ 
tion  of  the  slave. 

The  Single  Slave  Acknowledge  Word  shall  be  transmitted  from  the  slave  to 
the  master  during  the  Header  and  Data  Acknowledge  cycles  of  each  single  slave 
sequence.  The  master  Bus  Interface  should  pass  the  Single  Slave  Acknowledge 
Word  to  the  master  device. 

The  Single  Slave  Acknowledge  Word  format  shall  bo  as  shown  in  Figure  5~3 
and  specified  below. 

5. 2. 3. 3. 1.1  Slave  Module  Identification  Field  (MID).  The  Slave  Module  Iden¬ 
tification  field  shall  contain  the  MID  for  the  slave. 

5. 2. 3. 3. 1.2  Acknowledge  Word  Type  Field  (AMT).  The  Acknowledge  Word  Type 
(AWT)  field  shall  contain  a  two  bit  binary  code  as  specified  in  Figure  5-3. 
An  AWT  code  of  00  shall  specify  that  the  slave  has  closed  the  message  sequence 
with  this  header  or  data  acknowledge,  as  appropriate.  In  conjunction  with  an 
S  field  value  of  0.  an  AWT  of  00  shall  specify  message  complete.  In  conjunc¬ 
tion  with  an  S  field  value  of  1.  an  AWT  of  00  shall  specify  that  the  Acknowl¬ 
edge  Word  completes  the  slave's  response  to  a  Suspend  sequence  as  specified  in 
"5. 3. 5.1  Suspend. . "  AWT  codes  01,  10  and  11  shall  specify  that  the  slave  is 
acknowledging  the  completion  of  the  header  sequence.  The  codas  01  and  10  fur¬ 
ther  specify  that  the  slave  will  respond  to  a  Data  sequence  suspend  with  two 
nr  eight  Resume  Control  Words,  respectively.  The  S  field  code  shall  be  0  for 
an  AWT  code  of  01  or  10.  An  AWT  code  of  11  shall  further  specify  that  the 
slave  cannot  perform  a  suspend  sequence  during  the  current  message.  The  5 
field  code  shall  be  1  for  an  AWT  code  of  11.  The  slave  shall  use  an  AWT  code 
of  11  and  an  S  code  of  1  for  any  Bus  Interface  Message  Data  Acknowledge. 

5. 2. 3. 3. 1.3  Errors  Field.  The  slave  module  shall  specify  detected  errors  in 
bits  7  through  13  of  the  Acknowledge  word.  Errors  reported  in  the  Header 
Acknowledge  Word  shall  be  those  errors  that  originate  in  the  current  message 
from  the  start  of  the  Header  through  the  second  cycle  prior  to  the  Header 
Acknowledge.  Errors  reported  in  the  Data  Acknowledge  Word  shall  be  those 
errors  that  originate  in  the  current  message  from  one  cycle  prior  to  the  Head¬ 
er  Acknowledge  through  the  second  cycle  prior  to  the  Data  Acknowledge.  In 
addition  to  logging  current  message  error  indications,  the  Bus  Interface 
should  report  detected  errors  to  the  device  at  the  time  of  detection. 

The  definition  of  each  error  type  in  the  single  slave  acknowledge  word 
shall  be  as  listed  below: 

Correctable  Line  Error  A  signal  line  error  has  beer,  detected  and  cor¬ 

rected  . 

Uncorrectable  Line  Error  A  signal  line  error  that  cannot  be  corrected 
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has  been  detected. 

Sequence  Errer*  The  Cycle  Type,  Acknowledge  Set,  Wait  and  Bus 

Request  line  sequence  of  states  is  not  in 
agreement  with  defined  protocol  sequences  or 
rules. 

ProtffiCt  Error  A  Bus  Interface  Message  write  operation  has 

been  attempted  which  is  write  protected. 

Command  Error  A  Header  Word  A  has  been  received  which  is  not 

in  agreement  with  the  defined  protocol  or  the 
slave  is  unable  to  perform  the  commanded  opera¬ 
tion  because  the  current  bus  master’s  priority 
code  i  s  unknown. 

Resource  Not  Present  Error  A  resource  or  capability  that  is  not  imple¬ 
mented  has  been  addressed  in  this  module. 

Device  Error-  Module  device  has  detected  an  error  attempting 

to  perform  a  bus  related  operation. 

[  5. 2. 3. 3.1.S  Busy  Field  (B? .  The  slave  module  shall  specify  in  bit  1*  of  the 
|  Acknnwl edge  word  whether  the  slave  davice  is  Busy  or  not  Busy.  The  device 
shall  bs  recorded  cs  Busy  only  when  the  device  is  unable  to  accept  an  other¬ 
wise  valid  message  because  of  other  operations  in  progress.  The  master  should 
abort  any  sequence  in  which  the  slave  davice  is  specified  as  Busy.  The  master 
may  retry  the  massage  at  a  Inter  time. 

I  5, 2. 3. J. 1.5  Suspend  Field _ $.5_L.  The  slave  shall  specify  in  bit  15  of  the 

I  Header  Acknowledge  Word  whether  the  message  is  suspendable  or  not  suspendable. 

I  Only  Block  Messages  may  be  specified  as  suspendable.  The  slave  shall  specify 
I  in  bit  15  of  the  Data  Acknowledge  Word  whether  the  Data  Acknowledge  is  in 
I  response  to  a  Suspend  sequence  or  the  completion  of  the  message. 
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I  Figure  5-5.  Single  Sieve  Acknowledge  Word  Format  -  Date  Lines 
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5.2. 3. 3.2  Multiple  Slava  Acknowledge. 

I  A  Multiple  Slava  Acknowledge  sequence  shall  consist  of  one  bus  transfer 

I  cycle  to  transmit  aggregate  message  status  and  four  bus  transfer  cycles  to 
I  transmit  individual  acknowledge  bits.  The  first  transfer  cycle  shall  be  used 
I  by  each  slavo  to  transmit  a  Message  Status  Uord  to  the  master.  The  individual 
I  Message  Status  Uords  shall  be  wire-ORed  on  the  bus  to  form  an  aggrsgrate  Mes- 
I  sage  Status  Uord.  The  remaining  four  transfer  cycles  shall  be  used  to  trans- 
I  mit  multiple  slave  Acknowledge  symbols  from  the  slave(s)  to  the  master.  The 
I  five  transfer  cycles  are  labeled  HA0«  HA1,  HA2,  HAS  and  HA4  for  a  Multiple 
I  Slave  Header  Acknowledge  sequence  or  DAO,  DAI,  DA2,  DAS  and  DA4  for  a  Multiple 
I  Slave  Data  Acknowledge  sequence. 

I 

I  During  cycles  HAO  and  DAO,  slave  modules  shall  transmit  a  Message  Status 

I  word  to  the  master  using  Data  lines  <15... 0>.  The  format  of  the  Message  Sta- 
I  tus  word  shall  be  as  defined  in  Figure  5-4  and  Figure  5-5.  Data  lines 
I  <15...8>  shall  have  the  same  meaning  as  bits  <15... 8>  of  the  Single  Slave 
I  Acknowledge  klord  and  these  bits  shall  be  replicated  on  Data  lines  <7...0>, 

I  respectively,  to  permit  error  checking.  If  there  is  an  uncorr ectabl c  error  in 
I  the  Data  line  group,  the  module  shall  assume  that  both  lines  in  any  affected 
I  pair  of  redundant  lines  are  asserted.  For  Class  EC  messages,  bits  <15. ..8> 
I  shall  also  be  replicated  on  Data  Check  lines  <7...0>,  respectively,  to  permit 
I  error  correction.  Modules  shall  not  assert  any  Data  Group  line  on  cycle  HAO 
I  or  DAO  other  than  th«  lines  defined  above.  Tho  Master  Bus  Interface  should 
I  pass  the  aggregate  Message  Status  to  the  master  device. 

I 

1  Header  acknowledge  cycles  HA1  through  HA4  shall  be  used  to  transfer  "Ac- 

I  knowledge"  multiple  slave  acknowledge  symbols  from  the  slave(s)  to  the  master, 

I  Slave  modules  with  MID  values  0  through  7  shall  post  the  "Acknowledge"  symbols 
I  shown  in  Table  5~6  and  Table  5_7  on  the  Data  Group  during  cycle  HA1.  Slave 
I  modules  with  MID  values  8  through  15  shall  post  their  "Acknowledge"  symbol 
I  during  cycle  HA2  of  the  sequence.  Slave  modules  with  MID  values  16  through  23 
I  shall  post  thoir  "Acknowledge"  symbol  during  cycle  HA3  of  the  sequence  and 
t  slave  modules  with  MID  values  24  through  31  shall  post  their  "Acknowledge" 
I  symbol  during  cycle  HA4  of  the  sequence.  Modules  shall  not  assert  any  Data 
I  Group  -line  other  than  the  lines  included  in  their  symbol  on  their  assigned 
I  Acknowledge  cycle, 
j 

•  Data  acknowledge  cycles  DAI  through  DA4  shell  be  used  to  transfer  the 

I  "Acknowledge"  or  "No  Acknowledge"  multiple  slave  acknowledge  symbols  defined 
I  in  Table  5-6  ond  Table  5-7  from  the  slave(s)  to  the  master.  The  "Acknowledge” 
I  multiple  slave  Acknowledge  symbol  shall  be  posted  on  the  Data  Group  during  the 
I  assignrd  cycle  of  a  Data  Acknowledge  sequence  when  the  module  is  a  slave  and 
I  has  detected  no  uncorrectable  errors  in  tho  current  sequence.  Otherwise  the 
i  slave  shall  post  "No  Acknowledge”  during  the  assigned  Acknowledge  cycle. 

I  Slave  modules  with  MID  values  0  through  7  shall  post  their  multiple  slave 
I  Acknowledge  symbol  on  the  Data  Group  during  cycle  DAI.  Slave  modules  with  MID 
I  values  8  through  15  shall  post  their  multiple  solve  Acknowledge  symbol  during 
I  cycle  DA2  of  the  sequence.  Slave  modules  with  MID  values  16  through  23  shall 
I  post  their,  multiple  slave  Acknowledge  symbol  during  cycle  DA3  of  the  sequence 
I  and  slave  modules  with  MID  values  24  through  31  shall  post  their  multiple 
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I  slave  Acknowledge  symbol  during  cycle  DA4  of  the  sequence.  Modules  shall  not 
|  assert  any  Data  Group  Line  other  than  the  lines  included  in  their  symbol  on 
I  their  assigned  Acknowledge  cycle. 

The  multiple  slave  Acknowledge  symbols  posted  by  the  slave(s)  during  a 
particular  Acknowledge  cycle  shall  be  logically  GR'ed  on  the  bus'  to  produce 
I  one  of  the  four  Multiple  Slave  Acknowledge  Words  (AWfll,  AUM2,  AWM5  or  AWM4) 
which  shall  be  used  during  each  multiple  slave  acknowledge  sequence.  The  mas¬ 
ter  Bus  Interface  should  pass  the  Multiple  Slave  Acknowledge  Words  to  the  mas¬ 
ter  dev i ca. 

In  addition  to  posting  their  assigned  acknowledge  symbol,  slave  modules 
shall  post  the  symbol  ACK  (or  NAK  if  required  in  response  to  an  error)  on  the 
AS  lines  during  their  assigned  Acknowledge  cycle.  Slave  modules  shall  post 
the  symbol  NS  (or  HAK  if  required  in  response  to  an  error)  on  the  AS  lines  dur¬ 
ing  the  Acknowledge  cycles  in  which  they  are  not  assigned  to  post  their 
I  Acknowledge  symbol. 

Errors  shall  be  logged  during  multiple  slave  sequences  as  specified  for 
single  slave  sequences.  A  multicast  sequence  acknowledge  word  which  has  the 
same  format  and  information  that  a  Single  Slave  Acknowledge  Word  would  have 
had  if  the  sequence  had  been  a  single  slave  sequence  shall  be  stored  in  the 
Multicast  Acknowledge  Register  (see  "5-3. 7. 3.1  Multicast  Acknowledge  Regis¬ 
ter  -  Address  0.")  on  the  slavft’a  assigned  Header  Acknowledge  cycle.  During 
multiple  slave  Bus  Interface  Message  and  Block  Message  sequences,  a  word 
equivalent  to  the  Data  Acknowledge  word  for  a  single  slave  sequence  shall  be 
J  formed.  The  acknowledge  infer*, aiirn  stored  in  Multicast  Acknowledge  register 
I  bits  <14., 7>  on  the  Header  Acknowledge  cycle  shall  be  logically  OR'ed  with 
I  bits  <14.. 7>  of  the  equivalent  single  slave  Data  Acknowledge  word  and  the 
!  result  stored  in  bits  of  the  Multicast  Acknowledge  register  on  the 

I  slave's  assigned  Data  Acknowledge  cycle.  Bit  <15>  and  bits  <6..0>  of  the 
I  equivalent  single  slave  Data  Acknowledge  word  shall  be  stored  in  Multicast 
]  Acknowledge  Register  bit  <1S>  end  bits  <b..0>,  respectively,  on  the  slave's 
I  assigned  Data  Acknowledge  cycle.  All  detected  errors  should  be  reported  to 
the  dovice  at  the  time  of  detection. 

i 
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Figure  5-4.  Multiple  Slave  Status  Word  Format  (AWMQ)  -  Data  Lines 
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Figure  5-5.  Multiple  Slave  Status  Word  Format  -  Data  Check  Lines 

(Used  only  for  Class  EC) 
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Table  5'6 .  Multiple  Slave  Acknowledge  Symbol  Formats  (Four  Words) 


MODULE  ID  ASSIGNMENT 


AWM2 

AUM3 

AUM4 

n 

16 

24 

D 

17 

25 

10 

18 

26 

n 

19 

27 

12 

20 

28 

13 

21 

29 

14 

22 

30 

15 

23 

31 

DATA  LINES 


14  13  12  11  10  9  8  ?!  6  5  4  3  2 


A)  0=NO  ACKNOWLEDGE  /  1 =ACKN0WL EDGE 
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Table  5-7.  Multiple  Sieve  Acknowledge  Symbols  (Four  Word*) 
Data  Check  Lina  Formats  (Used  only  for  Class  EC) 


MODULE  ID  ASSIGNMENT 

DATA  CHECK  LINES 

AWM1 

AUM2 

AUM3 

AU1M4 

7 

6 

5 

4 

3 

2 

1 

0 

0 

8 

16 

24 

0 

0 

0 

0 

0 

0 

0 

A 

1 

9 

17 

25 

0 

0 

0 

0 

0 

0 

A 

0 

2 

10 

18 

26 

0 

0 

0 

0 

0 

A 

0 

0 

3 

11 

19 

27 

0 

0 

0 

0 

A 

0 

0 

0 

4 

12 

20 

28 

0 

0 

0 

A 

0 

0 

0 

0 

5 

13 

21 

29 

0 

0 

A 

0 

0 

0 

0 

0 

6 

14 

22 

30 

0 

A 

0 

0 

0 

0 

0 

0 

7 

IS 

23 

31 

A 

0 

0 

0 

0 

0 

0 

0 

A)  v -HO  ACKNOWLEDGE  /  i=AuKNuwLtDGt 
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5.3  DETAILED  REQUIREMENTS 

5.3.1  INTRODUCTION 

Detei led  requirements  for  the  Pl-bua  Date  Link  protocol  ere  specified  in 
this  section.  The  bus  states  which  govern  the  cycle-by-cycle  operation  of  the 
bus  are  defined  end  their  relationships  to  the  protocol  states  are  given.  The 
bus  mastership  protocol  is  specified,  including  requirements  for  the  use  of 
Bus  Request.  All  Pi-bus  communications  sequences  are  specified  by  sequence 
diagrams  which  show  the  scheduled  sequence  of  bus  states  and  corresponding 
module  operations.  Any  sequence  not  specified  herein  shall  be  considered 
invalid. 

The  protocol  for  using  Wait  to  insert  non-transfer  cycles  into  a  message 
sequence  is  specified.  The  Data  Link  facilities  which  are  required  to  be 
accessible  over  the  bus  ere  defined.  Finally,  bus  response  to  error  condi¬ 
tions  is  specified  and  bus  diagnostics  techniques  are  defined. 

5.3.2  BUS  STATE  DEFINITIONS. 

The  protocol  states  defined  in  "5.2  GENERAL  REQUIREMENTS."  consist  of 
sequences  of  bus  states.  The  bus  states  shall  define  the  information  content 
of  each  bus  cycle.  Table  5-8  lists  the  bus  states  along  with  their  corre- 
I  sponding  Cycle  Types  and  the  protocol  states  in  which  they  appear. 
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Each  of  tha  PX-bus  communication  sequences  defined  herein  has  a  corre¬ 
sponding  soquenca  diagram  which  shows  tha  required  schedule  of  bus  states  and 

tha  corresponding  bus  operations  for  that  sequence. 

Tha  Sequence  diagrams  contain  tha  following  information: 

ma-siAii 

BUS  Stitt  Unique  bus  state  is  shown  for  each  scheduled  bus  cycle, 

DATA 

D<31..16>  Data  format  type  or  state  for  the  most  significant  16  bits  of 

a  32  bi t  bus. 

D<15..0>  Data  format  type  or  state  for  the  16  bit  bus  or  tha  least  sig¬ 

nificant  16  bits  of  a  32  bit  bus. 

Source  Bus  Interface  driving  the  data  lines;  master  (fl)  or  slave  (S). 

Read  Source  Shows  cycles  where  the  slave  (S)  sources  the  Data  during  a 

read  sequence. 

write  Source  Shows  cycles  where  the  master  Cn)  sources  Data  curing  *  Write 
sequence. 

If  no  Source,  Read  Source  or  Write  Resource  is  shown,  data 
lines  are  released. 


Cycle  Type 


Defines  Cycle  Type  symbol  for  each  scheduled  bus  cycle. 


Source 


Shows  the  source  of  the  Cycle  Type  symbol  as  the  master  (M)  or 
a  contender  (C) . 


Acknowledge  Defines  the  state  of  the  Acknowledge  Set  lines  for  each  bus 
cycle.  The  AS  lines  may  be  driven  by  a  single  slave,  by  mul¬ 
tiple  slaves  or  by  contenders  in  Vie.  For  the  multiple  slave 
case,  an  NS  (Not  Selected)  beneath  ACK  means  that  an  NS  symbol 
may  appear  for  that  bus  cycle  if  there  are  no  sources  for  ACK 
during  that  cycle  out  of  the  group  of  potential  slave  (S) 


sources 
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Source  The  Acknowledoa  Source  is  shown  as  siave(s)  CS)  or 

contender(s)  (C)  or,  if  not  shown,  the  lines  ora  released. 

Source  <7-0>  For  multiple  slave  case,  the  Source  maybe  any  slave(s)  (S) 
with  an  MID  value  of  0  thru  7. 

Source  <15~S>  For  multiple  slave  case,  the  Source  maybe  any  slave(s)  (5) 
with  an  MID  value  of  8  thru  15. 

Source  <23-16>  For  multiple  slave  casa,  the  Source  maybe  any  slave(s)  (S) 
with  an  MID  value  of  16  thru  23. 

Source  <31-24>  For  multiple  slave  case,  the  Source  maybe  any  slave(s)  (S) 
with  an  HID  value  of  24  thru  31. 


WAIT 

Allowed  Defines  bus  cycles  where  Wait  may  be  asserted.  A  source  for 

Wait  is  not  shown  in  these  sequences  since  the  scheduled 
sequence  of  bus  states  assumes  that  Wait  is  not  asserted. 


A  set  of  four  colons  (::::)  in  a  sequence  diagram  indicates  that  a  number  of 
bus  states  occur  in  the  sequence  at  that  point. 
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5.3.3  BUS  MASTERSHIP. 

The  protocol  governing  bus  mastership  is  specified  herein.  The  Vie  and 
Tenure  Pass  Message  sequences  which  assign  bus  mastership  to  a  particular  mod¬ 
ule  are  defined.  The  protocol  which  allows  a  module  with  higher  priority  than 
the  current  bus  master  to  request  a  Vie  sequence  by  asserting  Bus  Request  is 
specified. 

5.3.3. 1  Vi  fl_£asngrigsu 

The  Vie  sequence  shall  be  used  to  determine  a  single  bus  master  for  the 
first  Header  sequence  which  occurs  after  the  bus  enters  the  Idle  state.  The 
bus  master  shall  be  selected  on  the  basis  of  the  Vie  Priority  code  stored  in 
each  contender's  Via  Priority  Register  (see  "5. 3.7. 3. 6  Vie  Priority  Register 
-  Address  5.R),  The  selected  bus  master  may  retain  tenure  or  may  assign  ten¬ 
ure  to  another  module  by  using  the  Tenure  Pass  Message  sequence  defined  in  the 
next  section. 

Any  module  that  requires  bus  mastership  may  initiate  Vie  after  two  or 
more  cycles  of  Idle.  Modules  shall  be  capable  of  participating  in  a  Vie 
sequence  which  begins  on  the  third  or  any  later  cycle  of  Idlo.  All  active  mod¬ 
ules  shall  monitor  each  step  of  the  Vie  process  and  store  the  Vie  Priority 
level  of  the  winning  module. 

Due  to  pipeline  delays,  a  module  may  attempt  to  initiate  Vie  up  to  one 
cycle  after  Vio  is  initiated  by  another  module.  In  that  case,  the  module 
which  attempted  to  initiate  the  late  Vie  sequence  shall  cease  to  contend  on 
next  cycle  and  shall  complete  the  original  Vie  sequence  as  a  non-contender . 
Modules  shall  not  attempt  to  initiate  Vie  more  than  one  cycle  after  thQ  V 
cycle  type  has  been  posted  on  the  Cycle  Type  lines. 

The  Vie  sequence  shall  be  a  four  step  sequence  as  defined  in  Table  5-9. 
Each  vie  step  shall  use  two  bus  cycles  to  resolve  three  of  the  twelve  bits  of 
Vie  Priority  code.  Modules  which  are  contending  for  bus  mastership  shall 
decode  the  three  most  significant  bits  ( VP<1 1 . . 9>)  of  their  Vie  Priority  coda 

i  n  i- a  K  :  .Li.  M _ I.  .  1  _  II  :  _  /• _ I  _ t  _  ▼_!  1  .  r-  «  a  i  -r  «  «  r-  «  m 

•  «  VM«  VI  viyiii  Iivuuiv  VIV  VVUV  CJ  Z»  SI1UWM  111  I  CIUJ.  V  ?  ’  i.  U  «rUI  IQD18  l  L  • 

Modules  shell  initiate  Vie  by  posting  the  Module  Vie  Coda  on  the  Data  line 
group  ana  the  V  cycle  type  on  the  Cycle  Type  lines.  On  the  following  bus 
cycle,  contenders  shall  release  the  Data  line  group. 
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Table  5-9.  Via  Sequence 


SUS  STATE 

SIGNAL  LINES 

VO 

V20 

VI 

VZ1 

V2 

VZ2 

V3 

VZ3 

DATA  M 

D<31 . . 16> 

0 

0 

0 

0 

0 

0 

0 

0 

D<15. .0> 

VCO 

0 

VC1 

0 

VC2 

0 

VC3 

c 

Source^ 

c 

c 

C 

C 

CYCLE  TYPE 

V 

V 

V 

V 

V 

V 

V 

V 

Sourc«=C 

ACKNOWLEDGE 

NS 

NS 

RCG 

RCG 

RCG 

RCG 

RCG 

RCG 

Source= 

c 

C 

C 

C 

C 

C 

WAIT 

0 

0 

0 

0 

0 

0 

0 

0 

Allowed 

NO 

NO 

NO 

NO 

ND 

NO 

NO 

NO 

STEP  SUB-CYCLE 

1 

2 

1 

2 

1 

2 

1 

2 

VIE  PRIORITY 

11.10,9 

8, 

>.6 

5,< 

1.5 

2. 

1,0 

CODE  BITS 

L  . 

VIE  STEP 

0 

1 

2 

3 

*  -  VCk  in  the  vio  code  formed  by  the  inclusive  ’OR*  of  the 
vie  codes  assarted  by  ell  contending  modules  (C). 


nodules  Siimi.l  i'mbq  the  icgicui~uR  of  the  nodule  Viv  Cvuvs  POstSu  by  thi 
contender:!!,  from  the  Data  line  group  at  the  end  of  the  first  cycle  of  Vie  (bus 
atnta  VO)  as  an  Aggregate  Vie  Code  (VCC).  During  the  second  cycle  of  each 
step*  each  contender  (C)  shall  compare  the  posted  Module  Vie  Code  to  the 
Aggregate  Vie  Cede  react  from  the  bus.  If  the  Aggregate  Vie  Code  reed  from  the 
bus  hui>  «i  bit  ftiiuertud  in  ci  more  significant  bit  position  than  the  Module  Vie 
Code  posted  by  the  module  them  the  module  has  lost  contention  and  shall  not 
drive  the  bus  on  any  remaining  cycles  in  the  Vie  sequence.  If  the  contender's 
posted  Module  Vie  Coda  has  the  some  bit  asserted  as  the  most  significant  bit 
asserted  in  the  Aggregate  Vie  Code  the  module  has  not  lost  the  vie  step  and 
shall  proceed  to  the  next.  Vie  step  as  a  contender.  If  there  is  an  uncorrecta- 
bj.e  error  vn  the  Data  line  group,  the  module  shall  assume  that  both  lines  in 
■Tiny  effected  pair  of  redundant,  lines  are  asserted. 
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Thf »  process  shall  ba  repeated  in  thsi  second,  third  and  fourth  via  steps 
using  Via  Priority  coda  bits  VP<8..A>#  Vp<5,.3>  and  VP<2..0>#  respec¬ 
tively.  At  ths  conclusion  of  the  fourth  via  step,  at  most  ona  module  remains 

as  a  contender  and  that  module  shall  become  the  now  bus  master.  If  a  bus  mas- 
tor  is  selected,  uniqueness  is  guaranteed  by  the  five  MID  bits  within  the  Vie 
Priority  Coda.  Tha  bus  master  must  post  HD  on  the  bus  cycle  immediately  fol¬ 
lowing  the  VZ3  cycle.  If  no  bus  master  is  selected  due  to  error  conditions# 
tha  bus  shall  return  to  tha  Idle  state. 

Table  5-9  defines  tha  detailed  sequence  of  bus  states  and  module  actions 

during  the  Vie  sequence.  The  Data  lines  ere  shown  as.  two  groups  of  sixteen 

lines  each.  Linos  D<31..16>»  if  implemented,  shell  rente. n  released  throughout 
tha  Vie  sequence.  Contending  modules  shall  post  their  Module  Via  Codes  on 
D<15..0>  and#  for  Class  EC  buses  only,  on  DC<7..0>.  The  Module  Vie  Codes 
posted  by  the  contending  modules  shall  be  logically  OR'ed  during  the  first 
cycle  of  each  vie  step  to  form  the  Aggregate  Vie  Code  for  that  step.  Conten¬ 
ders  shall  post  tha  symbol  V  on  the  Cycle  Type  lines  during  each  cycle  of  Via 
as  illustrated.  Contenders  shall  also  post  the  symbol  RCG  on  the  AS  lines 
during  each  cycle  of  the  second#  third  and  fourth  vie  steps.  All  active  mod¬ 
ules  shall  post  NAK  on  the  AS  lines  on  cycle  N+2  each  time  an  uncorrectabla 
Data  group  or  Cycle  Type  group  error  whici  applies  to  the  operation  of  bus 
cycle  N  is  detected. 

Modules  shall  not  assert  Wait  nor  Bus  Request  during  the  Vie  sequence. 
Non-contenders  shall  not  assert  any  line  or  post  any  symbol  during  the  Via 
sequence  iitiinr  than  puaLiiiy  NAK  on  tile  AS  lines  as  specified  above.  Ail 
activQ  modules  shall  monitor  the  Via  sequence  and  record  the  winning  bus  mas¬ 
ter's  priority  coda.  llncorrectablo  Data  cr  Cycle  Type  group  line  errors 
detected  during  the  Vie  sequence  shall  cause  tha  modules  which  do  not  win  the 
I  Vie  sequence  to  store  "unknown”  as  the  currant  bus  master's  priority  code, 
t  During  sub-cyclo  1  of  each  Vie  step#  Data  line  errors  for  bit  pairs  other  tha.' 
I  the  most  significant  pair  that  has  a  line  e.iserted  may  be  considered  correcta- 
I  hie  on  Class  ED  buses  since  the  winning  priority  is  not  affected.  A  module 
which  has  "unknown"  for  the  current  bus  master's  priority  code  shall  signal 
"command  error"  to  the  bus  master  if  the  module  becomes  a  slave  during  tha  bus 
master's  tenure  (see  "5.3.9  Error  Detection#  Recovery  And  Di  agnost i cs . r  ) . 
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5. 3. 3. 2  Tenure  Pass  Message 

The  current  bus  master  may  use  the  Tenure  Pass  Message  to  assign  bus 
mastership  directly  to  another  module.  The  current  bus  master  may  also  use 
the  Tenure  Pass  Message  to  begin  a  new  tenure  under  the  current  or  a  revised 
priority  code.  However*  the  Tenure  Pass  Message  shall  not  be  performed  if  Bus 
Request  Is  in  the  asserted  state  two  cycles  prior  to  the  HO  cycle  on  which  the 
Tenure  Pass  Massage  sequence  would  have  started. 

The  formats  which  shall  be  used  for  the  Tenure  Pass  Message  header  words 
arc  shown  In  Figure  5-6.  For  the  Tenure  Pass  Massage*  the  slave  ID  field  of 
Header  Word  A  (HUA)  shall  be  set  to  the  Module  Identification  (MID)  of  the 
module  which  shall  become  the  new  Bus  Master.  The  five  least  significant  bits 
of  HUB  must  be  the  same  as  the  five  least  significant  bits  of  HUA.  Bits  five 
through  seven  of  HUA  must  be  zero.  The  Format  (F)  bit  in  HWA  shall  be  0  and 
the  Type  16  sequence  shall  be  used  for  both  Type  16  and  Type  32  buses.  Header 
Word  E  (HUB)  shall  contain  the  new  bus  master  priority  code. 


Figure  5*6.  Tenure  Pass  Message  Header  Word  Formats 


HEADER  WORD  A  (HUA) 


AT 

MSG  TYPE 

F 

SLAVE  ID 

15 

13 

12 

li 

- 

9 

S 

7 

6 

5 

4 

3 

2 

1 

3 

1  0 

0 

0|  1 

0 

i 

oj  0 

o 

0 

MID 

I 

HEADER  WORD 

B  (HUB) 

L_1 

LIU 

m 

lUI 

m 

L^J 

\7I 

lifl 

LI  .  1 

r~i 

LU 

i 

LU 

m 

LU 

6|  5 

— i 

LU 

m 

L2J 

i 

LU 

— i 

LU 

n 

LU 

MSB 


LSB 


MSB  LSB 

NcU  MASTER  MODULE 
IDENTIFICATION  (MID) 


HEU  MASTER  LOGICAL 
PRIORITY  CODE 


RESERVED  (ZEROS) 


The  scheduled  sequence  cf  bus  states  for  the  Tenure  Pass  Message  shall 
be  as  shown  in  Table  5~12.  Each  bus  state  shall  use  one  bus  cycle  except  that 
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the  master  or  sieve  may  insert  non-transfer  cycles  into  the  sequence  by 
asserting  Wait  during  the  HZ  and/or  HAO  states. 

To  initiate  a  Tenure  Pass  Message*  the  bus  master  (M)  shall  post  HWA  on 
D<15..0>  aid  post  the  symbol  HO  on  the  Cycle  Type  (CT)  lines  during  the  HO 
state  of  the  Tenure  Pass  Message.  The  bus  master  shall  post  HUB  on  D<15..0> 
and  the  symbol  H  on  the  CT  lines  for  the  HI  state.  During  the  HZ  state*  tho 
Data  group  lines  shall  be  released  and  the  bus  master  shall  post  H  on  the  CT 
lines.  Also*  the  slave  (S)  shall  post  the  symbol  RCG  on  the  Acknowledge  Set 
group  lines.  On  the  HAO  state*  the  slave  shall  post  the  single  slave  Acknowl¬ 
edge  word  (AMS)  on  D<15..0>  and  shall  post  the  symbol  ACK  on  the  AS  group 
lines.  Also*  the  master  shall  post  the  symbol  A  on  the  CT  group  lines.  The 
bus  master  shall  post  A  on  the  CT  lines  and  the  slave  shall  post  ACK  on  the  AS 
group  lines  during  the  HAZ  state.  The  Data  group  lines  shall  be  released  dui — 
ing  KAZ. 

The  original  bus  master  shall  not  post  Abort  nor  post  Mait  on  HAZ  and 
shall  release  all  signal  lines  on  the  bus  cycle  following  HAZ.  The  original 
bus  master's  tenure  shall  end  with  the  HAZ  state  and  the  original  slave's  ten¬ 
ure  as  the  new  bus  master  shall  begin  on  the  next  bus  cycle. 

All  active  modules  shall  monitor  the  Tenure  Pass  Message  and  shall 
acquire  the  new  bus  master's  priority  code  from  HUB.  Any  module  that  detects 
an  errcr  in  the  Tenure  Pass  Message  shall  store  "unknown"  as  the  current  bus 
master's  priority  code.  A  module  which  has  "unknown"  for  the  current  bus  mas¬ 
ter's  priority  code  shall  signal  "command  error"  to  the  bus  master  if  the  mod¬ 
ule  becomes  a  slave  during  the  bus  master's  tenure  (see  "5.3.9  Error 
Detection*  Recovery  And  Diagnostics.”). 

The  Tenure  Pass  Message  shall  not  affect  the  Vie  Priority  Register  of  any 
module. 
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3. 5. 3. 3  a.U5.&R_qw&3-t-^ 

Tha  Bus  Request  lino  shall  be  assorted  by  a  modulo  to  signal  the  current 
bus  master  that  the  module  has  a  higher  priority  requirement  for  bus  master¬ 
ship.  The  module  asserting  Bus  Request  shall  ensure  that  this  condition  is 
met  by  only  asserting  Bus  Request  when  the  module's  Via  Priority  register  con- 
I  tains  a  higher  priority  code  than  that  of  the  current  bus  master.  A  module 
I  shall  not  assert  Bus  Request  when  the  current  bus  master's  priority  code  is 
I  unknown.  The  current  bus  master  shall  honor  Bus  Request  by  relinquishing  ten¬ 
ure  and  releasing  all  bus  signal  lines  by  tho  end  of  the  Vie  Interval  defined 
by  the  sum  of  the  bus  cycles  specified  by  the  contents  of  the  Via  Interval  A 
Register  plus  the  contents  of  the  Vie  Interval  B  Register  plus  six  cycles  (see 
"5. 3. 7. 3. 4  Vie  Interval  A  Register  -  Address  3."  and  "5. 3. 7. 3. 5  Vie  Interval 
B  Register  -  Address  4."). 

The  assertion  of  Bus  Request  shall  be  allowed  on  any  bus  cycle,  except 
for  the  cycles  starting  with  tha  third  cycle  of  Idle  and  continuing  through 
the  last  cycle  of  Vie.  If  a  module  asserts  Bus  Request  during  a  Tenure  Pass 
Message  and  the  new  bus  master  acquires  tenure  with  a  higher  priority  than  the 
module  asserting  Bus  Request,  the  module  shall  release  Bus  Request  within  six 
cycles  after  the  start  of  tha  next  bus  master's  tenure. 


The  bus  master  shall  count  all  bus  cycles,  including  non-transfer  cy-rles, 
whenever  Bus  Request  is  assarted.  The  first  cycle  counted  shall  be  the  first 
cycle  after  the  cycle  containing  the  initial  assertion  of  Bus  Request.  Any 


mtimammimn  A  1  in  *  m  i  iU  • 

w  <4,ii  v  wjrwie  l«i  mil  i  wi) 


Jus 


■  s  re  I sec 


ClUli  uS  CuUfiviu  Uliu 


shall  causa  the  accumulated  count  to  be  discarded, 
bus  master  may: 


To  relinquish  tenure,  the 


1.  release  all  bus  lines  to  place  the  bus  in  the  Idle  state  rather  than  post 
an  HO  cycle  or 

2-  if  a  single  slave  Block  Message  data  sequence  is  in  progress  and  the  AWT 
field  in  the  associated  Single  Slave  Header  Acknowledge  Word  is  010  or 
Oil,  the  bus  master  may  perform  a  Suspend  Sequence  (see 
"5. 3. 5.1  Suspend.")  and  release  all  bus  lines  before  the  total  Vie  Inter¬ 
val  time  elapses. 

If  the  cycle  count  reaches  the  sum  of  the  value  specified  in  the  Vie  Interval  A 
Register  plus  the  value  specified  in  the  Vie  Interval  B  Register,  the  bus  mas¬ 
ter  shall  perform  an  Abort  sequence  such  that  the  first  cycle  of  the  Abort 
sequence  occurs  on  the  second  bus  cycle  immediately  following  the  cycle  that 
exceeds  the  Vie  Interval  limit.  After  completing  the  Abort  sequence  the  mas¬ 
ter  shall  immediately  relinquish  tenure  and  release  all  bus  lines  (see 
"5. 3. 5. 2  Abort."). 
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5.3.4  MESSAGE  SEQUENCES 


5. 3.4.1  Parameter  Write  Message. 

The  Parameter  Write  Message  shall  be  used  to  transfer  a  one  word  parame¬ 
ter  from  the  master  device  to  a  slave  or  multiple  slave  devices.  The  Parame¬ 
ter  Write  sequence  of  bus  states  shall  be  as  defined  in  the  following  tables: 


Type  16,  single  slave  - 

Typo  16,  multiple  slave  — 

T yp«  32,  single  slave - 

Type  32,  multiple  slave  — 


Table  5-13 
Table  5-14 
Table  5-15 
Table  5-16 


Header  word  formats  for  the  Parameter  Write  message  shall  be  as  shonn  in 
Figure  5-7.  Header  Word  A  shall  specify  the  slave(s).  Type  16  or  32  Format, 
Access  and  Message  Types.  The  Access  Type  field  is  application  dependent, 
except  that  the  code  111  shall  be  reserved.  Message  Types  shall  be  as  defined 
for  the  single  slave  (SS)  and  multiple  slave  (MS)  cases.  Header  Word  B  shall 
contain  the  parameter  information  to  be  passed  to  the  device.  Header  Word  CO 
and  Cl  shall  contain  32  bits  of  virtual  addressing  information  to  be  passed  to 
the  defies. 


The  Header  Acknowledge  Word  (AUS)  shall  supply  current  message  status 
|  information  to  the  master  from  the  slave  for  single  slave  sequences.  For  mul- 
I  tiple  slave  sequences,  the  Multiple  Slave  Status  Word  (AWKO)  shall  supply  cir- 
I  rent  message  status  information  to  the  master.  The  multiple  slave  Header 
I  Acknowledge  Words  (AWM1,  AWM2,  AWH3,  AWM4)  convey  the  list  of  slave  partic¬ 
ipants  to  the  master. 
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Figure  5- 


7.  Parameter  Write  Header  Word  Formats 
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Table  5-13.  Parameter  Writs  Sequence  -  Type  16  Single  Slave  t 
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I  Table  5“14.  Parameter  Write  Sequence  -  Type  16  Multiple  Slave 
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Table  5-15.  Parameter  Write  Sequence  -  Type  52  Single  Slave 
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I  Table  5“16.  Parameter  Urite  Sequence  -  Type  32  Multiple  Slave 
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5 . 3 . * . 2  JLL^J!%aKisii^ 

The  Block  Message  *■  Short  Header  CSH)  Snutncn  nSuit.il  be  used  to  read  d .n t «ti 
from  ii  single  slave  device  to  the  master  device  or  to  write  dote  from  the  *ws- 
t#r  devit.w  to  one  or  nvor «  slave  davi  ees.  Thru  Bloch  Message  Short  Header 
sequence  of  bus  states  shall  be  as  defined  i r.i  the  fallnwing  tables:" 

Type  16,  single  slave  - -  Tattle  S-l? 

Type  16*  multiple  slave  Table  li~l& 

Type  32,  single  slave  . —  Table  5—1® 

Type  32,  multiple  slave  Table 

The  header  word  formats  for  the  Block  Message  ~  Short  Heads  r  sequence  shall  be 
«s  shown  in  Figure  5-4.  Header  Word  A  shall  specify  the  slave* s>  ID,.  Type'  16 
I  or  32  Format,  Access  and  Message  Types.  Access  Type  field  bit#  ‘(15,14  >  are 
|  application  dependant.  Bit  13  indicates  whether  the  message  vs  being  used  to 
|  resume  a  previously  suspended  Block  Message  (bit  13  1)  or  send  a  new  message 

I  (bit  13  =  Q).  The  Message  Types  shall  be  as  defined  for  the  single  sieve  write 
(S5M) ,  single  slave  reed  and  multiple  slave  (MS)  cases.  Header  Word  B 

shall  contain  airs  unsigned  binary  datum  count  which  specifiuia  the  number  of 
datum  units  to  b«  transferred  between  the  master  and  slave ( s) ,  except  that  all 
zeros  shall  represent  65,55b  datum  units.  The  datum  count  shell  be  th*  number 
of  3.6  bit  words  for  16  bit  transfers  or  the  number  of  double  words  for  32  bit 
transfers.  Header  Unrd  CO  and  Cl  shall  contain  32  bits  of  virtual  addressing 
information  to  be  passed  to  the  dev;ca.  When  the  Block  Message  -  Short:  Header 
|  is  used  for  resuming  a  suspended  single  slave,  musswgtii  (Header  Kurds  CO  and  Cl 
shall  be  the  two  Resume  Control  Words  sent  from  the  slave  to  the  master  during 
I  the  suspend  sequence  and  they  shall  be  returned  ir.i  the  order  received.  When 
|  the  Block  Mu  a  sage  is  used  for  rasuwing  n  suspended  multicast  niessacie,  the  coir 
I  tents  of  CO  and  Cl  should  be  defined  by  application  dependent  convention. 

The  Header  and  Da  to  Acknowledge*  Words  shall  supply  current  message  status 

{  ryf  ftraia  v  i  rm  r»  ^Ku  !*&'■»  + j»  y  c>  , 

Data  word  formats  are  application  specific.  The  number  of  words  or  dou¬ 
ble  words  transferred  for  each  Block  Message  -  Short:  Header  sequence  shall  be 
equal  to  the  value  in  Header  Word  B.  For  the  Typu  32  sequences,  dnta  words  are 
snown  with  1  or  H  designations.  Thu  least  significant  half  of  a  double  word  or 
a  single  word  transmitted  on  rfofn  lines  D<15'..ftf  contains  thin  I.  designation. 
The  most  significant  half  of  a  double  word  or'  s>  single  word  t  raniimi  tted  on 
data  linos  D<31..16>  contain*  the  K  designation. 


PZ-bus  Specification 


Version  2 


Figure  5- 


8.  Block  Message  -  Short  Header  Uord  Formats 
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Table  5-17.  Block  Message  -  SH  Sequence  ~  Type  16  Single  Slave 
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HAO 

DO 

:  :  :  : 

Dn 

DZ 

DAO 

DATA 

*• 

B 

■ 

BjM 

D<31 . . 16> 

0 

0 

0 

0 

HI 

0 

1  1 

:  s  2  : 

1 

MM 

0 

D<15. .0> 

HWA 

HUB 

HUGO 

HWC1. 

0 

AMS 

DO 

:  ;  ;  i 

m 

u 

AMS 

Source= 

n 

h 

M 

M 

S 

1 

S 

Read  Source^ 

S 

s 

HI 

■ 

Write  Source^ 

M 

M 

M 

B 

CYCLE  TYPE 

HO 

H 

H 

H 

H 

B 

b 

mu 

V 

| 

| 

Source=M 

H 

M 

H 

| 

ACKNOWLEDGE 

NS 

NS 

RCG 

RCG 

ACK 

RCC 

- 1 

rm 

B 

ACK 

Souree= 

S 

B 

S 

S 

S 

s 

B 

B 

S 

WAIT 

m 

B 

0 

0 

0 

0 

0 

■  ■  ■  ■ 

♦  ♦  *  * 

0 

\i 

0 

A1  lowed 

NO 

■  ■ 

YES 

YES 

YES 

YES 

YES 

YES 

YES 

YES 

YES 

Pi-bur  Specification 


Version  2.0 


I  Table  5~18.  Block  Heescpa  -  SH  Sequence  -  Type  16  Multiple  Slava 


BUS  STATE 

SIGNAL  LINES 

HO 

HI 

N2 

H3 

HZ 

HAO 

HA1 

HA2 

HAS 

HA4 

DATA 

D<31..16> 

0 

0 

0 

0 

0 

0 

0 

0 

0 

0 

D<15..0> 

HWA 

HWB 

HUGO 

HUC1 

0 

AWMQ 

AWM1 

AUM2 

AWM3 

AWM4 

Source= 

M 

M 

n 

M 

S 

S 

S 

S 

S 

CYCLE  TYPE 

HO 

K 

H 

H 

H 

A 

A 

A 

A 

A 

Souree=M 

ACKNOWLEDGE 

HS 

NS 

RCG 

RCG 

RCG 

ACK 

ACK 

ACK 

ACK 

ACK 

(NS) 

(NS) 

(NS) 

(NS) 

Source(7. „0)  = 

S 

S 

S 

S 

S 

SourceOS.  .8)  = 

s 

s 

s 

s 

S 

Source(23. .16)= 

s 

s 

s 

s 

S 

5ource( 31 . . 24)= 

s 

s 

s 

s 

S 

WAIT 

0 

0 

0 

0 

0 

0 

0 

0 

0 

0 

Allowed 

HO 

NO 

YES 

YES 

YES 

YES 

YES 

YES 

YES 

YES. 

. 
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f  Table  5-18.  Block  Mesaage  -  SH  Sequence  -  Type  18  Multiple  Sieve  (< 

I 


I BUS  STATE 


SIGNAL  LINES 

DO 

B 

Dn 

D2 

DAO 

DAI 

DA2 

DAS 

DA4 

DATA 

■ 

m 

■ 

D<31 . . 16> 

■X 

I 

> 

0 

0 

0 

0 

0 

D<15. -0> 

DO 

x  t ; : 

Dn 

mm 

AUMO 

AWM1 

AWM2 

AWM3 

AUM4 

Source3 

M 

n 

n 

B 

S 

S 

S 

S 

S 

CYCLE  TYPE 

■a 

n 

D 

B 

B 

B 

B 

B 

B 

Source=M 

■ 

B 

B 

B 

II 

II 

B 

B: 

ACKNOWLEDGE 

RCG 

!  4  {  • 

RCG 

RCG 

ACK 

ACK 

ACK 

ACK 

ACK 

(NS) 

(NS) 

(NS) 

(NS) 

Source?  7 . . 0 )  = 

S 

s 

S 

S 

S 

S 

Source? 15 . .8 ) = 

s 

s 

s 

s 

s 

S 

Source(23. .16)= 

s 

s 

s 

s 

s 

S 

Source?  51 .  .24 ) = 

s 

s 

s 

s 

s 

S 

WAIT 

0 

x  :  :  : 

0 

0 

0 

0 

0 

0 

0 

llUuPrj 

YES 

YES 

YES 

YES 

YES 

YES 

YES 

YES 

YES 

t 
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Table  5-19.  Block  Message  -  SH  Sequence  -  Type  32  Single  Slave 


BUS  STATE 

SIGNAL  LINES 

HO 

i 

HI 

HZ 

HAO 

DO 

tilt 

Dn 

DZ 

DAO 

DATA 

D<31 . . 16> 

HUB 

KUC1 

0 

0 

DOH 

:  :  :  > 

DnH 

0 

0 

D<15. .  0> 

HUA 

HUGO 

0 

AUS 

DOL 

:  x  x : 

DnL 

0 

AUS 

Source5 

fl 

M 

S 

S 

Read  Source5 

S 

s 

S 

Write  Source5 

M 

M 

M 

CYCLE  TYPE 

HO 

H 

H 

n 

m 

m 

b 

n 

n 

Source=M 

■ 

H 

Hi 

H 

■ 

ACKNOWLEDGE 

NS 

NS 

RCG 

ACK 

RCG 

•  •  «  « 

•  •  •  • 

RCG 

RCG 

ACK 

Source5 

S 

S 

S 

s 

S 

S 

S 

WAIT 

WM 

11 

0 

0 

0 

•  •  •  * 

•  •  a  • 

0 

0 

0 

Allowed 

B9 

Ea 

YES 

YES 

YES 

YES 

YES 

YES 

YES 

£ 

fe. 
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Table  5-20.  Block  Message  -  SH  Sequence  -  Type  32  Multiple  Slave 


SIGNAL  LINES 

HO 

HI 

DATA 

D<31 . . 16> 

HWB 

HUC1 

D<15 . . 0> 

HWA 

KWCO 

Source5 

M 

M 

CYCLE  TYPE 

HO 

H 

Source=M 

ACKNOWLEDGE 

HS 

NS 

Source(7. .0)= 
Sourest  15 . .8 ) - 
Source(23. .16)= 
Source(31 . .24)= 

WAIT 

AlloMed 


BUS  STATE 

HO  I  HI  I  HZ  KAO  I  HAl  HaTThaT  HA4 


0  0  0  0  0  0 

0  AMMO  AWM1  AWM2  AWM3  AWM4 

$  s  s  s  s 


RCG  ACK  ACK  ACK  ACtC  ACK 

(HS)  (NS)  (NS)  (NS) 
S  S  S 

S  S  S 

S  S  S 

S  S  S 

0  0  0  0  0  0 

YES  YES  YES  YES  YES  YES 
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I  Table  5-20.  Slock  Home*  ~  SH  Sequence  -  Type  32  Multiple  Sieve  (continued) 


SIGNAL  LINES 


DATA 

D<31 . . 16> 
D<15. . 0> 
Source^ 


CYCLE  TYPE 
Source=M 


ACKNOWLEDGE 


BUS  STATE 


DO  to:  On  DZ  DAO  DAI  DA2  DA J I  DA4 


DA2 

DA3 

0 

AWM2 

S 

0 

AWM3 

S 

Source(7.  .0)  = 

S 

s 

Source(15. .#)  = 

S 

s 

SourceC  23 . . 16  )  = 

s 

s 

Source(31. .24)= 

s 

s 

WAIT 

0 

•  •  •  • 

Allowed 

YES 

YES 

RCG  RCG  ACK  ACK  ACK  ACK  ACK 
(NS)  (NS)  (NS)  (NS) 
S  S  S  S 
S  S  S  S' 

s  s  s  s 

s  s  s  s 


YES  YES  YES  YES  YES  YES  YES  YES  YES 
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5.s.«.3  Hack JlmULgfl  .r-fwtaruigsLHgadar.-Stqvnoci. 

The  Block  Message  -  Extended  Header  (EH>  Sequence  shell  be  used  to  read 
data  from  *  single  slave  device  to  the  master  device  or  to  write  data  from  the 
master  device  to  one  or  more  slave  devices.  This  sequence  shall  bg  used  where 
floro  header  information  is  required  than  that  provided  by  the  Block  Message 
short  header  sequence.  The  Block  Message  -  Extended  Header  sequence  of  bus 
states  shall  be  as  defined  in  the  following  tables: 

Type  16*  single  sieve  — —  Teble  5-21 

Type  16.  multiple  slave  —  Table  5-22 

Type  32.  single  slave  — — -  Teble  5-23 

Type  32>  multiple  sieve  —  Teble  5-24 

Header  word  formats  for  the  Block  Message  -  Extended  Header  sequence  shall  be 
es  shown  in  figure  5-9.  Header  Word  A  shall  specify  the  slave(s)  ID.  Type  16 
I  or  32  Fermat.  Access  and  Message  Types.  Access  Type  field  bits  <15,14>  are 
|  application  dependent.  Bit  13  indicates  whether  the  message  is  being  used  to 
I  resume  a  previously  suspended  Block  Message  (bit  13  =  1)  or  send  a  new  message 
i  (bit  13  =  0).  The  Message  Types  shall  be  as  defined  for  the  single  slave  write 
(SSW).  single  slave  read  (SSR)  and  multiple  slave  (MS)  cases.  Header  Word  B 
shall  contain  in  vrisiyniid  binary  datum  count  which  specifies  the  number  of 
datum  units  to  be  transferred  between  the  master  and  slave(s)>  except  that  all 
zeros  shall  represent  65.536  datum  units.  The  datum  count  shall  be  the  number 
of  16  bit  words  for  16  bit  transfers  or  the  number  of  double  words  for  32  bit 
transfers.  Header  Word  CO  end  Cl  shell  contain  32  bits  of  virtual  addressing 
information  to  be  passed  to  the  device.  When  the  Block  Message  -  Extended 
I  Header  is  used  for  resuming  a  suspended  single  slave  message.  Header  Words  CO 
and  Cl  shall  be  the  first  two  Resume  Control  words  sent  from  the  slave  to  the 
-  master  during  the  suspend  sequence  and  shall  be  returned  in  the  order 
received.  Header  Words  DO  thru  D5  ere  also  application  dependent  and  shall  be 
I  passed  to  the  slave  device.  When  resuming  a  suspended  single  slave  message 
these  words  shall  be  the  last  six  Resume  Control  Words  sent  from  the  slave 
I  during  the  suspend  sequence  and  shall  be  returned  in  the  order  received.  When 
I  the  Block  Message  is  used  for  resuming  a  suspended  multiple  slave  message,  the 
I  contents  of  HWCO.  HWC1  end  HUDO  through  HWD5  should  be  defined  by  application 
I  dependent  convention. 
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Flyura  5 


f.  Block  Masaaga  -  Extandad  Haadar  Word  Formats 
HEADER  WORD  A  CHWA) 


AT 

MSG  TYPE 

F 

SLAVE  ID 

15 

21 

13 

12 

0 

10 

9 

6 

7 

6 

5 

A 

3 

0 

1 

0 

ACCESS 

TYPE 


1101-ssw 

1100-SSR 

1111-MS 


HEADER  WORD  B  (HUB) 


0 

13 

12 

11 

10 

9 

□ 

7 

6 

5 

A 

3 

R 

i 

0 

15 


MSB  < - - DATUM  COUNT 

HEADER  WORD  CO  CHWCO) 


->  LSB 


0 

14 

13 

0 

— 

0 

10 

0 

8 

7 

6 

5 

4 

3 

2 

1 

0 

15  < -  LEAST  SIGNIFIcANi  AuuKtSS  BITS — - »  0 

HEADER  WORD  Cl  (HUC1) 


0!! 


0 

12 

11 

10 

9 

8 

7 

6 

5 

4 

3 

2 

1 

□ 

31  - -MOST  SIGNIFICANT  ADDRESS  BITS - - - >  16 

HEADER  WORD  DO  (HWDO) 


0 

0 

13 

0 

11 

10 

9 

8 

0 

6 

5 

4 

-I 

2 

0 

MSB 


LSB 


K 

M 

M 


HEADER  WORD  D5  CHWD5) 


M 

K 

M 


K 

M 

X 


0 

14 

13 

SB 

i: 

0 

8 

E 

E 

5 

4 

3 

2 

1 

0 

MSB 


LSB 
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Table  5-21 


Block  Message  -  EH  Sequence  -  Type  16  Single  Slav 


BUS  STATE 

SIGNAL  LINES 

HO 

HI 

H2 

H3 

H4 

BUI 

H9 

HZ 

HAO 

DATA 

D<51. -16> 

0 

0 

0 

0 

0 

0 

B 

0 

D<15 . .0> 

KWA 

HUB 

HUCO 

HUC1 

HUDO 

HWD5 

AUS 

Source- 

M 

n 

M 

M 

M 

M 

M 

■ 

s 

CYCLE  TYPE 

HO 

H 

H 

H 

H 

mm 

H 

H 

B 

Source=M 

m 

B 

ACKNOWLEDGE 

N5 

NS 

RCG 

RCG 

RCG 

•  •  •  • 

RCG 

RCG 

ACK 

Scurce= 

S 

S 

S 

s 

S 

S 

S 

WAIT 

m 

11 

0 

0 

0 

0 

0 

0 

0 

Allowed 

O 

KB 

YES 

YES 

YES 

YES 

YES 

YES 

YES 
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Table  5-21.  Block  Message  -  EH  Sequence  -  Type  16  Single  Slave  (continued) 


BUS  STATE 

SIGNAL  LINES 

DO 

D1 

D2 

:  :  :  : 

Dn 

DZ 

DAO 

DATA 

D<31 . . 16> 

0 

0 

0 

: : :  : 

0 

0 

0 

D<15. .C> 

DO 

D1 

D2 

:  :  :  : 

Dn 

0 

AMS 

Source2 

S 

Read  Source2 

S 

S 

S 

s 

S 

Write  Source2 

M 

M 

M 

M 

M 

CYCLE  TYPE 

D 

D 

D 

•  ♦  J  • 

D 

D 

A 

Source-M 

ACKNOWLEDGE 

RCG 

RCG 

RCG 

;  ;  ;  ; 

RCG 

RCG 

ACK 

Source2 

S 

S 

S 

s 

S 

.  S 

S 

WAIT 

0 

0 

0 

:  » »  : 

0 

0 

0 

Allowed 

YES 

YES 

YES 

YES 

YES 

YES 

YES 
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I  Table  5-22.  Block  Mesaape  ~  EH  Sequence  -  Type  16  Multiple  Slave  (continued) 

1 


BUS  STATE 

SIGNAL  LINES 

HA3 

HA4 

DO 

B 

Dn 

DZ 

DAO 

DAI 

DA2 

DA  3 

DA4 

DATA 

■ 

■ 

■ 

■ 

D<31 . . 16> 

3 

0 

I 

1 

0 

0 

0 

0 

0 

D<15. -0> 

AWM3 

AUM4 

DO 

iisiH 

mm 

AMMO 

AWM1 

AWM2 

AWM3 

AWM4 

Source= 

S 

S 

"j 

L" 

B 

B 

S 

S 

S 

S 

S 

CYCLE  TYPE 

n 

n 

B 

mm 

B 

B 

B 

B 

B 

II 

B 

Sourca=M 

■ 

1 1 

B 

m 

■ 

■ 

B 

m 

II 

B 

II 

ACKNOWLEDGE 

ACK 

ACK 

RCG 

•  ;  ;  ; 

RCG 

RCG 

ACK 

ACK 

ACK 

ACK 

ACK 

(NS) 

(NS) 

(NS) 

(NS) 

(NS) 

(NS) 

Source(7. .0)= 

S 

s 

S 

S 

S 

S 

SourcQ<15. .§)= 

s 

s 

s 

s 

S 

S 

SourceC  2  3 . .  16  )  = 

S 

s 

s 

s 

S 

s 

S 

Sourest  31 . . 24  )  = 

S 

s 

s 

s 

s 

S 

S 

WAIT 

0 

0 

0 

•  •  J  » 

0 

0 

0 

0 

0 

0 

0 

Allowed 

YES 

YES 

YES 

YES 

YES 

YES 

YES 

YES 

YES 

YES 

YES 
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Table  5-23.  &  loci'  Massage  -  EM  Sequence  Type  32  Single  Slave 


SIGNAL  LINES 
DATA 

D«C3i..lfi> 

D<15..0> 

Source” 

CYCLE  TYPE 
Scurce=M 

ACKNOWLEDGE 

5ource:: 

WAIT 
A1  lowed 


BUS  STATE 


HO 

HI 

H2 

1 - 

H3 

H4 

HUB 

MUC1 

HMD1 

HWD.5 

HMDS 

HU  A 

HWCO 

HWDO 

HWD2 

HWD4 

K 

M 

M 

K 

M 

HO 

H 

H 

H 

H 

NS 

NS 

RCG 

RCG 

RCG 

S 

S 

S 

0 

0 

a 

0 

0 

NO 

NO 

YES 

YES 

YES 

& 

R»tf» 
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Table  5-23,  Block  Message  -  EH  Sequence  -  Type  32  Single  Slave  (continued) 


Pi-bus  Speci f I  cat i on  Version  2.0 

Table  5-24.  Block  Message  -  EH  Sequence  -  Type  32  Multiple  Slave 


DATA 

D<31..16> 
D<15.  .0> 
Source* 


CYCLE  TYPE 
Source*!! 


ACKNOWLEDGE 

Sourco(7 . . 0 )* 
Sourest  15 . . S )  = 
Sourcof  23 . . 16 ) : 
Sourest  31 . . 24 ) : 


All  oi-jsd 


BUS  STATE 


H2 

H3  1 

HWD2 

HUDO 

nw»H 

M 

M 

H 

H 

RCG 

RCG 

s 

S 

s 

S 

s 

s 

S 

s 

0 

0 

YES 

YES 

HAO 

HA1 

HA2 

HAS 

HA4 

0 

0 

0 

0 

0 

AWMO 

AWM1 

AWM2 

AWM3 

AWM4 

S 

S 

S 

S 

S 

S  s 

s  s 

s  s 

s  s 


ACK 

ACK 

ACK 

(NS) 

(NS) 

(NS) 

S 

S 

S 

0 

0 

0 

YES 

YES 

YES 
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I  Tab, l a  5-S4.  Block  Massage  -  EH  Sequence  **  Type  32  Multiple  Slava  (continued) 

I 


BUS  STATE 

SIGNAL  LINES 

DO 

:  i  z  : 

1 

Dn 

DZ 

DAO 

DAI 

DA2 

DA3 

DA4 

DATA 

D<31 . . 1G> 

DON 

sts* 

DnH 

0 

0 

0 

0 

0 

0 

D<15. .0> 

DDL 

:  :  s  s 

DnL 

0 

AUMO 

AWM1 

AUM2 

AWM3 

AWM4 

Source5 

M 

M 

M 

S 

S 

S 

S 

5 

CYCLE  TYPE 

D 

till 

D 

D 

A 

A 

A 

A 

A 

Sourco-N 

ACKNOWLEDGE 

RCG 

s  :  s  i 

RCG 

RCG 

ACK 

ACK 

ACK 

ACK 

ACK 

(MS) 

(NS) 

(NS) 

(NS) 

Sourc«(7, .0)= 

S 

s 

S 

S 

S 

S 

Sourc®( IS  .  .11 ) 5 

s 

s 

s 

s 

s 

S 

Source(2J. -16)— 

s 

s 

s 

s 

s 

S 

Source!  31 . . 24 ) 5 

s 

s 

s 

s 

s 

S 

WAIT 

0 

•  ;  ;  • 

0 

0 

0 

0 

0 

0 

0 

Allowed 

YES 

YES 

YES 

YES 

YES 

YES 

YES 

YES 

YES 
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5. 3. 4. 4  Bus  Interface  Message  Sequence 

The  Bus  Interface  Message  shall  be  used  to  read  or  write  to  the  Bus 
Interface  register  address  spaces.  The  Bus  Interface  Message  sequence  ef  bus 
states  shall  be  as  defined  in  the  following  tables: 

Type  16,  single  slave  -  Table  5-25 

Type  16,  multiple  slave  —  Table  5-26 

Header  word  formats  for  the  Bus  Interface  Message  sequence  shall  be  as  shown 
in  Figure  5-10.  Header  Word  A  shall  specify  the  participant  slave(s),  Type  16 
Format,  Access  and  Message  Types.  The  same  format  shall  be  used  for  both  Type 
16  end  Type  32  buses.  Access  Type  coda  000  is  defined  for  the  Data  Link  regis¬ 
ter  address  space.  Codes  001  through  Oil  shall  be  reserved  for  higher  level 
protocols  and  the  code  111  shall  be  reserved  for  future  use.  The  other  codes 
may  be  used  for  implementation  defined  registers.  The  Message  Types  shall  be 
as  defined  for  the  single  slave  write  (SSU),  single  slave  read  (SSR)  and  mul¬ 
tiple  slave  (MS)  cases.  Header  Uord  B  shall  contain  the  address  for  the  first 
Bus  Interface  register  to  be  accessed  in  the  sequence  and  an  unsigned  binary 
word  count  specifying  the  number  of  data  words  to  be  transferred  between  the 
master  and  the  slave(s),  except  that  a  word  count  of  all  zeros  shall  mean  256 
words.  Each  data  transfer  after  the  first  data  transfer  shall  access  a  suc¬ 
cessive  register  address.  The  register  address  shall  ba  incremented  after 
each  data  word  transfer. 

Data  word  formats  are  as  defined  in  "5.3.7  Data  Link  Facilities.."  The 
number  of  data  words  transferred  shall  equal  the  value  in  Header  Uord  B. 
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Figure  9-10.  Bus  Interface  Message  Header  Word  Formats 


HEADER  WORD  A  CHWA) 


HEADER  WORD  B  (HUB) 


15  14  13  12  11  10 

— 

9  8 

7  6  5  4  3  2 

1  0 

MSB 

LSB 

MSB 

LSB 

WORD  COUNT 

REGISTER  ADDRESS 
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Table  5-25.  Bus  Interface  Message  Sequence  -  Type  IS  Single  Sieve 

I  BUS  STATE  I 


HO  I  HI  I  HZ  I  HAD  DO 


Dn  DZ  DAO 


SIGNAL  LINES 

HO 

DATA 

D<31..1*> 

0 

D<15. .0> 

HWA 

Source- 
Reed  Source" 
Urite  Source= 

n 

CYCLE  TYPE 
Source=M 

HO 

ACKNOWLEDGE 

Source1 

NS 

WAIT 

0 

Allowed 

NO 

CG 

ACK 

S 

S 

0  0  0  :  i  :  :  0  0  0 

YES  YES  YES  YES  YES  YES  YES 
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Tabla  5-26.  Bus  Interface  Message  Sequence  -  Type  16  Multiple  Slave 


BUS  STATE 


SIGNAL  LINES 


DATA 

D<31..1«> 
D<15 . . 0> 
Source^ 


CYCLE  TYPE 
Source=M 


0  0 
HWA  HUB 
M  M 


HA0 

HA1 

0 

AWM0 

S 

0 

Auni 

s 

HA2 

HAS 

HA4 

0 

AWM2 

S 

0 

AS4M3 

S 

0 

AWM4 

S 

ACKNOWLEDGE 

Sourca(7. .0)= 
SourceC 15. .8)= 
SourceC  23 . . 16 ) : 
SourceC  31 . .24): 


RCG  ACK  ACK  ACK  ACK  ACK 
(NS)  (NS)  (NS)  (NS) 
S  S  S 
S  S  S 

S  S  S 

S  S  S 


WAIT 

Allowed 


0  0  0  0  0 

YES  YES  YES  YES  YES 
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I  Table  5-26.  Bus  Interface  Message  Sequence  -  Type  16  Multiple  Slave  (continued) 

1 


BUS  STATE 

SIGNAL  LINES 

00 

q 

Dn 

DZ 

DAO 

DAI 

DA2 

DAS 

DA  4 

DATA 

H 

■ 

■ 

B 

D<31 . . 16> 

H 

1 . 1 

0 

0 

0 

0 

0 

D<15. .0> 

DO 

•  •12 

. 

0 

AWMO 

AUM1 

AWM2 

AUM3 

AUM4 

Source= 

M 

M 

HI 

S 

S 

S 

S 

CYCLE  TYPE 

■a 

mm 

■a 

sa 

B 

m 

■a 

SI 

B 

Source-M 

H 

m 

H 

HI 

■1 

B 

1 

■ 

B 

ACKNOWLEDGE 

RCG 

s : :  : 

RCG 

RCG 

ACK 

wm 

ACK 

ACK 

ACK 

HYB1 

(NS) 

(NS) 

(NS) 

Source(7. .0)= 

S 

S 

S 

S 

S 

|K9 

Source! 15. .6): 

s 

s 

s 

s 

s 

S 

Source(23. .16)= 

s 

s 

s 

s 

s 

s 

SourceC  31 . .  24  )  = 

s 

s 

S 

s 

s 

■ 

S 

WAIT 

0 

J  •  *  • 

H 

0 

0 

0 

at  i  _  _ _ i 

1  «“«««« 

vrr 

■  LW 

vrr 
•  LU 

wm 

vte 

♦  k.  u 

VCf 

1  kv 

vcc 

•  «-  u 
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5.3.5  EXCEPTION  SEQUENCES. 


5.3.5. 1  Suspend. 

I  The  current  bus  master  may  elect  to  suspend  a  Block  Message  during  the 

Date  sequence  providing  that  there  are  at  least  three  Data  Cycles  remaining 
|  and  the  corresponding  Header  Acknowledge  Word  had  an  S  of  1  and.  for  single 
(  slave  messages,  an  AMT  of  01  or  10.  After  completing  the  Suspend  sequence, 
the  current  bus  master  may  initiate  a  new  massage  with  an  HO  cycle  or  release 
the  bus  to  initiate  the  Idle  state. 


The  Suspend  Sequence  may  be  used  in  conjunction  with  the  Vie  Interval  A 
and  Vie  Interval  B  Registers  to  optimize  the  trade-off  between  short  bus 

{  acquisition  latency  and  large  message  sizes  by  allowing  a  Block  Message  to  be 
interrupted  and  resumed  at  a  later  time. 

I 

I  5. 3. 5. 1.1  Single  Slave  Suspend. 

I 

I  The  Suspend  sequence  of  bus  states  for  single  slave  Block  Messages  shall 

be  as  defined  in  the  following  tables: 


Type  16.  single  sieve,  short  data  — --  Table  5-27 
Type  32.  single  slave,  short  data  ----  Table  5-28 


Type  16.  single  slave,  extended  data  -  Table  5-29 


Type  32.  single  slave,  extended  data  -  Table  5-30 


The  Short  Date  Sequence  shall  be  used  if  the  AMT  field  of  the  Single  Slave 
I  Acknowledge  Word  from  the  suspended  message  was  01.  The  Extended  Data 
|  Sequence  shall  be  used  if  the  AMT  field  was  10.  In  terms  of  tho  data  transfer 
Operation,  the  S  cycles  of  these  sequences  shall  be  considered  normal  D  cycles 
and  all  Bus  Interfaces  shall  respond  accordingly.  The  slave  shall  post  ACK 
during  the  last  of  the  three  S  cycles  to  indicate  that  the  Suspend  Sequence 
has  been  recognized. 


Beginning  on  the  fourth  cycle  of  a  Suspend  sequence,  the  slave  shall 
transmit  to  the  bus  master  i mpl emento t i on/dev i ce  specific  Resume  Control 
Words  that  the  master  shall  store  for  later  use  in  resuming  the  message.  The 
5"spend  -  Short  Data  sequences  transfer  two  Resume  Control  Words  and  the  Sus¬ 
pend  -  Extended  Data  sequences  transfer  eight  Resume  Control  Words.  The 
Resume  Control  Words  shall  be  followed  by  a  Data  Acknowledge  Word. 

5. 3. 5. 1.2  Multiple  Slave  Suspend. 

The  Suspend  sequence  of  bus  states  for  multiple  slave  Block  Messages 
shall  be  as  defined  in  the  following  tables: 

Typa  -16.  multiple  slove - -  Table  5-31 
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Type  32,  multiple  slave -  Table  5-32 

In  terms  of  the  data  transfer  operation,  the  S  cycles  of  these  sequences  shall 
be  considered  normal  D  cycles  and  all  Bus  Interfaces  shall  respond 
accordingly.  The  slaves  shall  post  ACK  during  the  last  of  the  three  S  cycles 
to  indicate  that  the  Suspend  Sequence  has  been  recognized.  A  non-transfer  DZ 
cycle  and  a  multiple  slave  Data  Acknowledge  sequence  shall  follow  the  third  S 
cycle.  No  Resume  Control  Words  are  sent  from  the  slaves  to  the  master. 

5. 3. 5. 1.3  Resuming  Suspended  Messages 

A  master  shall  resume  a  suspended  Block  Message  by  transmitting  the 
remaining  data  to  the  slave(s)  in  a  Block  Message  with  bit  13  of  the  HWA  AT 
field  set  to  1.  The  Resume  Control  Words  that  the  slave(s)  may  require  to 
resume  that  message  shall  be  sent  to  the  slave(s)  during  the  appropriate  head¬ 
er  cycles  as  described  in  "5. 3. 4. 2  Block  Message  -  Short  Header  Sequence.” 
and  "5. 3. 4. 3  Block  Message  -  Extended  Header  Sequence.. "  For  a  single  slave 
message,  the  Resume  Control  Words  shall  be  those  words  transmitted  from  the 
slave  to  the  master  during  the  suspend  sequence.  For  a  multiple  slave 
message,  the  Resume  Control  Words  must  be  created  by  the  master  according  to 
the  slaves'  resume  control  requirements. 

A  Block  Message  -  Short  Header  shall  be  used  to  resume  a  suspended  single 
slave  Block  Message  which  had  an  AWT  field  of  01  (two  Resume  Control  Words) 
and  a  Block  Message  -  Extended  Header  shall  be  used  to  resume  a  suspended  sin¬ 
gle  slave  Block  Message  which  had  an  AWT  field  of  10  (eight  Resume  Control 
Words).  The  type  of  Block  Message  used  to  resume  a  multiple  slave  message 
shall  be  determined  by  the  slaves'  resume  control  word  requirements. 

Note  that  the  choice  of  a  short  or  extended  header  Block  Message  for  the 
resume  sequence  is  not  determined  by  whether  a  short  or  extended  header  was 
used  in  the  suspended  Block  Message. 

I 

i  5. 3. 5. 1.4  Using  Suspend  With  Vie  Intervals  A  and  B 

The  r I -bus  Vie  Interval  A  end  Vie  Interval  s  Registers  may  be  used  by 
soma  bus  interfaces  to  determine  when  a  Suspend  sequence  is  required  to  meet 
the  Vie  Interval  requirement  and  to  limit  the  number  of  non-transfer  cycles 
caused  by  assertion  of  Wait  during  a  Suspend  sequence.  Vie  Interval  A  may  be 
selected  to  define  a  checkpoint  where  the  master  bus  interface  determines 
whether  or  not  to  suspend  an  incomplete  Block  Message.  Vie  Interval  B  may  be 
selected  to  define  the  number  of  bus  cycles  allowed  for  completion  of  the  Sus¬ 
pend  sequence,  including  non-transfer  cycles  that  may  be  required  as  a  result 
of  Waits.  If  the  actual  number  of  Waits  causes  the  total  bus  cycles  to  exceed 
the  number  specified  by  the  contents  of  the  Vie  Interval  A  Register  plus  the 
contents  of  the  Vie  Interval  B  Register,  the  master  shall  perform  an  Abort 
sequence  such  that  the  first  cycle  of  the  Abort  sequence  occurs  on  the  second 
bus  cycle  immediately  following  the  cycle  that  exceeds  the  Vie  Interval  limit. 
This  Abort  cycle  shall  be  the  first  cycle  in  the  Abort  Sequence,  described  in 
"5. 3- 5. 2  Abort.."  At  tho  end  of  the  Abort  sequence  the  master  shell  imme¬ 
diately  release  the  bus  to  the  Idle  state. 
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Table  5-27.  Suspend  -  Short  Data  Sequence  -  Type  16  Single  Slave 


BUS  STATE 

SIGNAL  LINES 

Di 

D  f  ♦  1 

Di  +2 

RDO 

RD1 

DZ 

DAO 

DATA 

D<31 . . 16> 

0 

0 

0 

0 

0 

0 

0 

D<15 . . 0> 

Di 

Di  +1 

Di  +2 

RCDO 

RCD1 

0 

AWS 

Source- 

S 

S 

S 

Need  Source2 

S 

S 

S 

Write  Source2 

M 

M 

h 

CYCLE  TYPE 

S 

S 

s 

D 

D 

D 

A 

Source2M 

ACKNOWLEDGE 

RCG 

RCG 

ACK 

RCG 

RCG 

RCG 

ACK 

Source= 

S 

S 

S 

S 

S 

S 

S 

WAIT 

0 

0 

0 

0 

9 

0 

0 

Allowed 

Source= 

YES 

YES 

YES 

YES 

yes 

YES 

YES 

B--94 
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Table  5-29.  Suspend  -  Extended  Date  Sequence  -  Type  16  Single  Slave 


BUS  STATE 

SIGNAL  LINES 

Di 

Di  +1 

Di  +2 

RDQ 

RD1 

:  :  :  : 

RD7 

DZ 

DAO 

DATA 

D<31 . .16> 

0 

0 

0 

0 

0 

0 

0 

0 

D<15.,0> 

Di 

Di  +1 

Di  +2 

RCDO 

RCD1 

:  :  j  : 

RCD7 

0 

AWS 

Source= 

S 

S 

S 

S 

s 

Read  Source5 

S 

S 

S 

Write  Source5 

n 

n 

M 

CYCLE  TYPE 

s 

s 

S 

D 

D 

*  J  J  • 

D 

D 

A 

Souree=M 

ACKNOWLEDGE 

RCG 

RCG 

ACK 

RCG 

RCG 

:  :  :  : 

RCG 

RCG 

ACK 

Source= 

S 

S 

S 

S 

S 

s 

S 

S 

S 

WAIT 

"  ■ 

0 

0 

0 

0 

0 

j  ;  ♦  ; 

0 

0 

0 

Allowed 

Source= 

YES 

YES 

YES 

YES 

YES 

YES 

YES 

YES 

YES 
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Table  5-30.  Suspend  -  Extended  Data  Sequence  -  Type  32  Single  Slave 


BUS  STATE 


SIGNAL  LINES 

Di 

1 - 

Di  +1 

Di  +2 

DATA 

D<31 . . 16> 

DiH 

Di+IH 

Di  +2H 

D<15 . . 0> 

Di  L 

Di+iL 

Di  +2L 

Source= 

Read  Source" 

S 

S 

S 

Writs  Source" 

M 

M 

M 

CYCLE  TYPE 

S 

S 

S 

Sourc*=f1 

ACKNOWLEDGE 

RCG 

RCG 

ACK 

Sourca= 

S 

S 

S 

WAIT 

0 

0 

0 

A1 lowed 
Source= 

i 

YES 

YES 

YES 

RD1 

RD2 

RCD3 

RCD2 

S 

RCD5 

RCD4 

S 

:CG 

RCG 

RCG 

RCG 

ACK 

S 

S 

S 

S 

S 

0  0  0  0  0  0 

YES  YES  YES  YES  YES  YES 
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Table  5-31. 


BUS  STATE 

SIGNAL  LINES 

Di 

Di  +1 

Di  +2 

DZ 

DAO 

DAI 

DA2 

DAS 

DA4 

DATA 

m 

■ 

D<31 . .  16> 

|Q 

0 

0 

0 

0 

0 

0 

0 

D<15 . . fl> 

Di  +1 

Di  +2 

0 

AWMO 

AWM1 

AWM2 

AWM3 

AWM4 

Source1 

■3 

H 

M 

S 

S 

S 

S 

CYCLE  TYPE 

s 

S 

S 

■a 

I 

B 

m 

B 

Source=M 

■ 

■ 

B 

B 

B 

B 

ACKNOWLEDGE 

RCG 

RCG 

ACK 

RCG 

ACK 

ACK 

ACK 

ACK 

ACK 

(NS) 

(NS) 

(NS) 

(HS) 

SourceC7. .0)= 

S 

S 

S 

S 

S 

S 

5ource(15, ,8)  = 

s 

s 

s 

s 

s 

S 

Source(23. . 16  )  = 

s 

s 

s 

s 

s 

S 

Source(31 . .24)= 

s 

s 

s 

s 

s 

S 

WAIT 

0 

0 

RS 

0 

0 

0 

0 

0 

0 

Allowed 

YES 

YES 

mm 

IS 

YES 

YES 

YES 

YES 

YES 
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Table  5-32.  Suspend  -  Type  32  Multiple  Slave 


BUS  STATE 


SIGNAL  LINES 

Di 

Di  +1 

Di  *2 

DATA 

D<31 . . 16> 

DiH 

Di+IH 

Di  +2H 

D<15 . . 0> 

Di  L 

Di+IL 

D  i  +21 

Source= 

M 

M 

M 

CYCLE  TYPE 
Source=M 

S 

S 

S 

ACKNOWLEDGE 

RCG 

RCG 

ACK 

5ource( 7 , . 0 ) = 

S 

S 

S 

Source( 15. .  8 )  = 

S 

S 

s 

Source(23 . . 16 ) = 

s 

s 

s 

Source!  31 . . 24 )  = 

s 

s 

s 

WAIT 

0 

0 

0 

Allowed 

YES 

YES 

YES 

g 


0  0  0  0  0 

AWMO  AWM1  AWM2  AWM3  AWM4 

s  s  s  s  s 


0  0  0 
YES  YES  YES 


ACK 

ACK 

(NS) 

(NS) 

S 

S 

0 

0 

YES 

i 

YES 

5.3.S.2  AhacAx. 

The  Abort  Sequence  may  be  used  to  terminate  a  message  prior  to  completion 
due  to  errors  or  other  reasons.  Ho  header  or  acknowledge  words  ere  required 
for  the  Abort  sequence.  A  master  may  initiate  the  Abort  Sequence  at  any  time 
during  its  tenure*  excjept  the  last  cycle  of  a  Tenure  Pass  Message. 

The  Abort  Sequence  shall  be  as  shown  in  Table  5-53.  The  first  three  of 
the  tour  bus  cycles  with  the  AB  cycle  type  are  used  to  give  the  slave  time  to 
recognize  thot  an  abort  has  occurred.  The  slave  (or  slaves  in  the  case  of  mul¬ 
ticast  or  broadcast)  shall  respond  by  posting  ACK  on  the  AS  lines  during  the 
third  AB  cycle  to  inform  the  master  that  an  Abort  has  been  recognized.  There 
are  no  slaves  on  the  fourth  At  cycle  end  the  master  is  the  only  module  that  may 
assert  Wait  on  that  cycle.  After  the  last  AB  cycle*  the  master  may  continue 
with  the  HO  of  another  message  or  relinquish  control  of  the  bus  by  releasing 
the  bus  signal  lines. 
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Table  5-33.  Abort  Sequence 


BUS  STATE  j 

SIGNAL  LINES 

ABO 

AB1 

AB2 

AB3 

DATA 

P<31 . . 16> 

X 

X 

0 

0 

D<15 . . 0> 

X 

X 

0 

0 

Source1 

fl  or 

K  or 

S 

S 

CYCLE  TYPE 

AB 

AB 

AB 

AB 

Source^M 

ACKNOWLEDGE 

X 

X 

ACK 

NS 

Source^ 

X 

X 

S 

WAIT 

0 

0 

0 

0 

Allowed 

a 

a 

NO 

b 

Source= 

a 

a 

b 

e)  Sieve  Wait  assertion  allowed 
but  not  honored  by  master 
b)  Master  Wait  allowed, 
no  slaves  exist 
X)  not  defined 


5,3.6  WAIT. 
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A  master  or  slave  may  assert  Wait  to  control  the  data  transfer  rate  on  ‘v.^ 

the  Pi-bus  and  thereby  accommodate  slow  or  temporarily  busy  devices.  During  a  ■ 

multiple  slave  sequence,  one  or  more  of  the  slaves  may  assert.  Wait.  Each 
cycle  on  which  Wait  is  asserted  shall  cause  the  insertion  of  a  non-transfer 
cycle  into  a  sequence.  ;>w 


5 . 3 . 6 , l  Rules  for  Asserting  Wait. 

A  Bus  Interface  may  assert  Wait  on  ono  or  more  cycles  subject  to  the  fol¬ 
lowing  restrictions: 

1.  Wait  may  normally  be  asserted  by  a  Dus  Interface  only  if  that  module  is 
scheduled  to  be  a  bus  master'  or  slave  on  the  noxt  transfer  cycle.  Howev¬ 
er,  the  current  bus  master  may  assert  Wait  if  the  bus  will  bo  placed  in 
the  Idle  state  following  the  Wait  induced  non-transfer  cycle(s)  provider! 


\V 
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the  vie  interval  requirement  ia  not  violated, 

2.  A  Bus  Interface  shall  not  assert  Wait  on  HO  or  HI  cycles. 

3.  A  Bus  Interface  shall  not  assert  Wait  on  a  particular  cycle  (N),  if  on 
the  second  previous  cycle  (N-2)  the  module  did  not  assert  Wait  but  Wait 

|  mas  asserted  on  that  cycle.  If  the  Bus  Interface  does  assert  Wait  on 

I  cycle  N  and  Wait  Mas  not  asserted  by  any  module  on  cycle  N-l,  the  Bus 

I  Interface  shall  assert  Wait  for  an  even  number  of  contiguous  cycles. 

5. i. 6. 2  Effects  of  Wait. 

Other  than  during  an  Abort  sequence,  for  each  cycle  that  a  Watt  is 
asserted  during  e  tenure,  one  non-transfer  cycle  (NT  cycle)  shall  be  inserted 
into  the  sequence  immediately  following  the  cycle  in  Hhich  Wait  is  asserted. 
The  insertion  of  non-transfer  cycles  shall  not  change  the  sequence  of  sched- 
I  uled  bus  states.  However,  if  during  the  NT  cycle,  the  master  asserts  an  Abort 
|  sequence  designation  on  the  Cycle  Type  lines,  the  sequence  shall  be  altered  to 
I  Abort.  During  art  Abort  sequence,  Wait  shall  not  introduce  non-transfer 
cycles . 


5. 3. 6. 2.1  Line  Groups  during  Non-Transfer  Cycles 

During  NT  cycles  produced  by  Wait,  the  signal  line  values  shall  be  as 
specified  below. 

5. 3. 6. 2. 1.1  Data  line  Group  during  NT  Cvqle^.  The  value  on  the  Data  lines 
shall  be  ignored  except  for  line  error  checking.  Only  valid  symbols  shall  be 
posted  on  the  Data  line  group. 

The  Data  line  group  shall  not  be  posted  by  any  module  other  than  the  mod¬ 
ule  which  would  have  posted  the  Data  lines  had  that  cycle  been  the  scheduled 
transfer  cycle.  If  e  module  asserts  a  value  on  the  Data  line  group  on  such  an 
NT  cycle,  the  value  shall  be  a  symbol  which  is  valid  for  the  next  scheduled 
transfer  cycle. 

5. 3. 6. 2. 1.2  Cycle  Type  Group  during  NT  Cvclos.  The  value  on  the  CT  lines 
I  shall  be  ignored  except  for  line  error  checking  and  the  occurrence  of  Abort. 
I  An  Abort  Cycle  Type  shall  mark  tho  beginning  of  an  Abort  Sequence.  The  master 

module  responsible  for  posting  the  CT  lines  on  the  next  scheduled  transfer 
cycle  sh«l 1  source  e  valid  symbol  on  the  C7  lines  during  the  NT  cycle(s). 

5. 3. 6. 2. 1.3  AS  Group. duri pq  NT  Cycles.  If  a  module  is  responsible  for  post¬ 
ing  the  AS  lines  on  the  next  transfer  cycle  it  shall  post  a  valid  symbol  on  the 
AS  lines  during  the  NT  cycle(s).  A  symbol  other  than  NAK  shall  be  ignored  dur- 

|  ing  non-transfer  cycles.  NAK  shall  be  posted  on  cycle  N,  to  signal  that  an 
error  associated  with  cycle  N-2  was  detected. 

5.3.6.2-l.t  Ha 1 1 _ l  ines  during  NT  Cycle?.  The  rules  for  asserting  Wait  ere 

specified  in  "5.3.6. 1  Rules  for  Asserting  Wait..**  The  effects  of  asserting 
Wait  on  a  non-transfer  cyclo  shall  be  the  same  as  specified  herein  for  assert- 
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ing  Wait  on  a  transfer  cycle. 

S. 3. 6. 2. 1.5  Bus  Request  tines  during  NT  Curies.  The  rules  for  asserting  Bus 
Request  are  specified  in  "5. 3. 3. 3  Bus  Request.. "  Bus  Request  is  completely 
independent  of  Wait. 

5.3.7  DATA  LINK  FACILITIES. 

This  section  specifies  the  Data  Link  facilities  which  shall  be  accessible 
over  the  Pi-bus  via  the  Bus  Interface  Message  described  in  *5. 3. 4. 4  Bus 
Interface  Message  Sequence." 

5.3.7. 1  Data  Link  Register  Address  Space. 

The  Data  Link  facilities  specified  herein  shall  be  contained  in  the  Data 
Link  register  address  space  which  shall  consist  of  256  words  assigned  to  con¬ 
secutive  addresses.  This  register  space  shall  be  allocated  as  shown  in 
Table  5-34.  Access  to  these  facilities  over  the  bus  shall  be  allowed  only  via 
the  Bus  Interface  Message  with  the  Header  Word  A  Access  Type  field  set  to  zero 
(AT-000  )  . 

Reserved  registers  shall  not  be  implemented  and  any  attempt  to  access 
them  shall  cause  a  'Resource  Hot  Present*  error.  For  write  operations  to 
defined  registers,  the  state  of  any  bits  in  the  word  which  correspond  to 
reserved  bits  shall  be  ignored. 
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Table  5-34.  Date  Link  Register  Address  Space 


ADDRESS  REGISTER 


255 

. 

LOGICAL  SLAVE 

• 

IDENTIFICATION 

m 

REGISTERS 

C33  -  255) 

33 

32 

. 

RESERVED  REGISTERS 

(6  -  32) 

b 

5 

VIE  PRIORITY  REGISTER 

4 

VIE  INTERVAL  B  REGISTER 

3 

VIE  INTERVAL  A  REGISTER 

2 

MODULE  CAPABILITIES  REGISTER 

1 

CONTROL  REGISTER 

0 

MULTICAST  ACKNOWLEDGE  REGISTER 
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9. 3. 7. 2  Register  Protection. 

Access  to  the  Date  Link  registers  via  the  Bus  Interface  Message  shall  be 
limited  by  write  protection.  Either  permanent  or  programmable  write  pro~ 
taction  shall  be  provided  for  each  register  as  specified  in  the  following  sec** 
tions.  The  current  state  of  programmable  write  protect,  must  be  controlled 
from  the  device.  On  reset*  all  programmable  protection  must  be  placed  in  the 
non-protect  state. 


5.3.7. 3  Reai stera* 

5. 3. 7. 3.1  Multicast  Acknowledge  Register  -  Address  0. 

The  Multicast  Acknowledge  Register  shall  be  a  16  bit  register  with  the 
same  format  and  field  interpretations  as  the  Single  Slave  Acknowledge  word. 
During  Multicast  sequences*  error  information  shall  be  accumulated  by  the 
slave.  This  information  is  identical  to  that  required  for  the  single  slave 
case  The  acknowledge  word  which  would  have  been  transferred  to  the  master  if 
the  current  sequence  was  a  single  slave  sequence*  shall  be  stored  in  the  Mul¬ 
ticast  Acknowledge  Register  instead  of  being  sent  as  an  A  US .  and  the  Multicast 
Acknowledge  symbol  shall  be  posted  on  the  bus.  Error  indications  shall  apply 
to  the  current  message  only. 

During  multiple  slave  Bus  Interface  Message  and  Block  Message  sequences* 
a  word  equivalent  to  the  Data  Acknowledge  word  for  a  single  slave  sequence 
shall  be  formed.  The  acknowledge  information  stored  in  Multicast  Acknowledge 
I  register  bits  <14., 7>  on  the  Header  Acknowledge  cycle  shall  be  logically  OR'ed 
I  with  bits  <14.. 7>  of  the  equivalent  single  slave  Data  Acknowledge  word  and  tho 
I  result  stored  in  bits  <14.. 7>  of  the  Multicast  Acknowledge  register  on  the 
I  slave's  assigned  Data  Acknowledge  cycle.  Bit  <15>  and  bits  <6..0>  of  the 
i  equivalent  single  slave  Data  Acknowledge  word  shall  be  stored  in  Multicast 
|  Acknowledge  Register  bit  <15>  and  bits  <6..0>  on  the  slave's  assigned  Data 
Acknowledge  cycle.  This  Register  shall  be  reset  at  the  start  of  a  multi-slave 
message  in  which  this  module  is  a  participant. 

The  following  requirements  shall  apply  to  the  Multicast  Acknowledge  Reg- 

i ster : 

Word  format:  Figure  5“11 

Write  protect:  Permanent 

I 

I  State  after  reset:  Bit  <15>=1*  Bits  <14..5>=all  zeros*  Bits  <4..0>=MID 
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Figure  5-11.  Multicast  Acknowledge  Register  Word  Format 
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ERRORS 

AWT 

SLAVE  MID 

15 

14 

13 

12 

11 

10 

9 

£ 

7 

6 

5 

4 

3 

2 

1 

□ 

I  I  I  I  I  I 

< —  1=  ERROR - > 

<—  0=  NO  ERROR - > 


MSB  LSB 

SLAVE  MODULE  IDENTIFICATION 


ACKNOWLEDGE  WORD  TYPE 
00  (S=l)  -  MESSAGE  COMPLETE 
00  (S  =  0>  -  MESSAGE  SUSPENDED 

01  -  HEADER  COMPLETE,  DATA  EXPECTED 

CS=0)  2  RESUME  CONTROL  WORDS 

10  -  HEADER  COMPLETE,  DATA  EXPECTED 

(5-0)  8  RESUME  CONTROL  WORDS 

11  -  HEADER  COMPLETE,  DATA  EXPECTED 
(5=1)  SLAVE  NOT  5USPENPABLE 


CORRECTABLE  LINE  ERROR 


UNCORRECTABLE  LINE  ERROR 


SEQUENCE  ERROR 


PROTECT  ERROR 


COMMAND  ERROR 


RESOURCE  NOT  PRESENT  ERROR 


DEVICE  ERROR 


DEVICE  BUSY  0  -  NOT  BUSY 
1  -  BUSY 


HEADER  ACKNOWLEDGE: 


0  -  SU5PENDABLE 
1  -  NOT  SUSPENDABLE 


DATA  ACKNOWLEDGE: 


0  -  MESSAGE  SUSPENDED 
1  “  MESSAGE  COMPLETE 
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5. 3. 7. 3. 2  Control  Register  -  Address  1. 

The  Control  Register  shall  be  a  2  bit  register  that  shall  contain  a  bit 
to  initiate  Bus  Interface  reset  end  e  bit  to  initiate  built-in-test. 

The  following  requirements  shall  apply  to  the  Control  Register: 

Word  format:  Figure  5-l2 

Wri te  protect:  programmable 

State  after  reset:  all  zeros. 

Reserved  bits:  read  as  zeros. 

Figure  5-12.  Control  Register  Word  Format 
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RESERVED  (ZEROS) 


INITIATE  BUILT-IN-TEST 
0  =  NO  INITIATE  ** 

1  =  INITIATE 


BUS  INTERFACE  RESET 
0  =  NO  RESET  X 
1  =  RESET 


*  -  Placed  in  0  state  at  completion  of  reset. 

-  Placed  in  0  state  at  completion  of  'built-in-test'. 
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5. 3. 7. 3. 3  Modulo  Capabilities  Register  -  Address  2. 

The  Module  Capabilities  Register  shall  be  a  3  bit  register  that  shall 
specify  the  physically  implemented  capabilities  of  the  Bus  Interface  /  Device 
Combination. 

The  following  requirements  shall  apply  to  the  Module  Capabilities  regis¬ 
ter  : 

Word  format:  Figure  5-13 

Write  protect:  permanent 

State  after  reset:  appropriate  capabilities  code 
Reserved  bits:  read  as  zeros. 


Figure  5"13.  Module  Capabilities  Register  Word  Format 
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3 

2 

1 

3 

RESERVED  (ZEROS) 


FEATURE  0  =  SLAVE  ONLY 

1  =  MASTER/SLAVE 


CLASS  0  =  ED  (ERROR  DETECT) 

1  =  EC  (ERROR  CORRECT) 


TYPE  0  =  TYPE  16  (16  BIT  TRANSFERS) 

l  =  TYPE  32  (32  OR  16  BIT  TRANSFERS) 


MM 
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5. 3. 7. 3. 4  Via  Interval  A  Register  -  Address  3. 

The  Vie  Interval  A  Register  shall  be  a  IS  bit  register  that  shall  contain 
the  unsigned  binary  Vie  Interval  A  timeout  value  expressed  in  bus  cycles.  The 
value  in  this  register  shall  remain  unchanged  until  a  new  timeout  value  is 
loaded.  Reading  this  register  shall  return  the  last  value  written.  This  reo* 
i  ster  is  not  required  for  Feature  SO  modules.  Any  attempt  to  access  a  regis¬ 
ter  which  is  not  implemented  shall  cause  a  'resource  not  present'  error. 

The  following  requirements  shall  apply  to  the  Via  Interval  A  Registers 
Word  format:  Figure  5-14 

Wri te  protect:  programmable 

State  after  reset:  all  ones 


Figure  5-14.  Vie  Interval  A  Register  Word  Format 
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5. 3. 7. 3. 5  Via  Interval  B  Register  -  Address  A. 

The  Via  Intarval  B  Register  shall  be  an  8  bit  register  that  shall  contain 
the  unsigned  binary  Vie  Interval  B  timeout  value  expressed  in  bus  cycles.  The 
value  in  this  register  shall  remain  unchanged  until  a  new  timeout  value  is 
loaded.  Reading  this  register  shall  return  the  last  value  written^  This  reg¬ 
ister  is  not  required  for  Feature  SO  modules.  Any  attempt  to  access  a  regis¬ 
ter  which  in  not  implemented  shall  cause  a  'resource  not  present'  error. 

The  following  requirements  shall  apply  to  the  Vie  Intarval  B  Register: 

Word  format:  Figure  5-14 

Write  protect:  programmable 

State  after  reset:  Bits  <15..S>»  all  zeros;  bits<7..0>»  all  ones 


Figure  5-15.  Vie  Interval  B  Register  Word  Format 
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5. 3. 7. 3.6  Via  Priority  Register  -  Address  5. 

The  Via  Priority  Register  shall  be  a  12  bit  register  that  shall  contain 
the  current  vie  priority  of  this  module  expressed  in  unsigned  binary  rotation. 
The  priority  range  is  from  zero  (lowest  priority),  to  4095  (highest  priority). 
This  register  is  divided  into  two  fields.  The  module  identification  field 
shall  ba  fixed  by  the  module's  hardwired  module  identification  code  (MID)  and 
cannot  be  changed  by  the  Bus  Interface  Message.  This  register  is  not  required 
for  Feature  50  modules.  Any  attempt  to  access  a  register  which  is  not  imple¬ 
mented  shall  cause  a  'resource  not  present*  error. 

The  following  requirements  shall  apply  to  the  Vie  Priority  register: 

Word  format:  Figure  5~16 

Write  protect:  Programmable  for  bits<11..5>»  bits<5..0>  fixed  by  MID 

State  after  resot:  Bits<11..5>.  ail  zeros;  bits<4..0>=  MID  bits<4..0> 

Reserved  bits:  read  as  zeros. 


Figure  5-16.  Vie  Priority  Register  Word  Format 
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5. 3. 7. 3. 7  Reserved  Registers  -  Addresses  6  To  32. 

The  use  of  the  Reserved  Registers  shall  be  defined  only  by  future  ver¬ 
sions  of  this  specification.  Until  then,  these  registers  shall  not  be  imple¬ 
mented  and  shall  cause  a  ’Resource  Not  Present*  error  if  an  access  is 
attempted. 

5. 3. 7. 3. 8  Logical  Slave  Identification  Registers  -  Addresses  33  to  255. 

The  Logical  Slave  Identification  Registers  consist  of  a  set  of  one  bit 
registers  in  locations  33  to  255  of  the  Data  Link  register  address  space.  The 
address  of  each  register  is  identical  to  the  Slave  Identification  code  which 
the  register  controls.  Bit  0  of  each  Logical  Slave  ID  register  indicates 
whether  or  not  a  Slave  Identification  code  (ID)  equivalent  to  the  register 
address  will  be  recognized  by  the  module  as  a  valid  slave  ID.  The  interpreta¬ 
tion  of  bit  0  shall  be: 

1  ~  Bus  Interface  shall  recognize  this  address  as  a  slave  ID. 

0  =  Bus  Interface  shall  not  recognize  this  address  as  a  slave  ID. 


The  following  specifications  shall  apply  to  the  Logical  Slave  Identifi¬ 
cation  Registers: 

Wri te  protect :  programmable 

State  after  reset:  zero 

Reserved  bits  (15~1):  read  as  zeros. 

This  register  set  i,  optional.  A  subset  of  the  Logical  Slave  ID  Regis¬ 
ters  may  be  implemented  using  either  ona  or  a  combination  of  the  two  methods 
specified  below: 

1.  The  Logical  Slave  ID  Registers  may  be  implemented  directly  as  a  set  of 
one  bit  register^  in  the  Bus  Interface  register  space.  The  slave  iden¬ 
tification  registers  shall  have  consecutively  decreasing  addresses 
storting  at  address  255.  Any  number  of  registers  may  be  implemented  from 
zero  up  to  the  full  set  of  223.  The  module  shall  not  respond  to  sequences 
with  Slave  ID's  corresponding  to  registers  which  are  not  implemented. 
Any  attempt  to  access  registers  that  are  not  implemented  via  a  Bus  Inter¬ 
face  Message  shall  cause  a  'resource  not  present'  error. 

2.  The  Logical  Slave  ID  registers  may  be  implemented  indirectly  using  tech¬ 
niques  such  as  associeti vely  searching  for  valid  slave  ID's.  In  that 
case,  the  implementation  shell  specify  the  number  of  unique  Logical  Slave 
ID's  which  can  be  recognized  (J  to  223)  and  each  of  those  shall  be  capa¬ 
ble  of  being  set  by  the  standard  Bus  Interface  Message  to  any  value  in 
the  range  33  to  255,  inclusive.  The  standard  Bus  Interface  Message  shall 
also  be  capable  of  invalidating  any  previously  validated  slave  identifi¬ 
cation  coda.  Any  attempt  to  validate  more  logical  slave  ID's  than 
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allowed  by  the  implementation  shall  causa  a  'resource  not  present*  error. 
Figure  5-17.  Logical  Slave  Identification  Register  Word  Format 


15  14  13  12  11  10  9  8  7  6  5  4  3  2  1  0 


RESERVED  (ZEROS) 


0  =  DO  NOT  RECOGNIZE  THIS  REGISTER  ADDRESS 
AS  A  VALID  SLAVE  ID 

1  =  RECOGNIZE  THIS  REGISTER  ADDRESS 
AS  A  VALID  SLAVE  ID 


5.3.8  INITIALIZATION. 

A  reset  mechanism  shall  be  provided  to  initialize  the  Bus  Interface. 
\  Reset  shall  be  invoked  by  tha  attached  device  or  by  completion  of  a  Bus  Inter- 
I  face  Message  that  set  bit  0  (when  not  write  protected)  of  the  control  regi  star 
(see  "5. 3. 7. 3. 2  Control  Register  -  Address  1.").  The  Bus  Interface  shall 
respond  to  reset  by  becoming  inactive,  releasing  all  bus  drivers  and  initial¬ 
izing  Data  Link  registers  to  the  values  defined  in  "5.3.7  Data  Link  Facili¬ 
ties.."  Following  register  initialization,  modules  may  become  active  on  the 
bus  provided  that  MID<4 . . 0>//MIP<0>  satisfies  P(MID<4 . . 0>//MIP<0>)  =1.  A 
module  with  incorrect  MID  parity,  that  is  P(MID<4 . . 0>//MIP<0>)  =  0,  shall  not 
assert  any  Pi-bus  signal  and  shall  not  participate  in  Pi-bus  operations.  A 
potential  bus  master  module  shall  not  initiate  a  Vie  sequence  prior  to  deter¬ 
mining  that  the  bus  has  been  Idle  for  a  minimum  of  two  bus  cycles  and  shall  not 


operating  at  a  lower  priority  than  tha  potential  bus  master's  priority. 
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3.3.9  ERROR  DETECTION .  RECOVERY  AND  DIAGNOSTICS. 

This  section  describes  the  detection  of  end  responses  to  line,  sequence 
and  semantic  errors.  This  section  also  defines  Pi-bus  diagnostics  require¬ 
ments. 

5 . 3 . 9 . 1  Correctable  line  Errors 

If  the  bus  symbol  error  is  correctable*  then  the  symbol  shall  be  func¬ 
tionally  interpreted  as  the  valid  symbol  with  the  least  coding  distance  from 
the  erroneous  symbol.  During  message  sequencer*  errors  shall  be  logged  in  the 
|  Acknowledge  word  by  setting  the  'Correctable  Line  Error'  bit  to  one  (refer  to 
*5. 2. 3. 3.1  Single  Slave  Acknowledge.").  The  device  should  be  notified  of 
detected  errors. 

5. 3.9.2  Uncorrectable  Line  Errors 

If  the  bus  symbol  is  uncorrectable*  then  the  symbol  shall  be  func¬ 
tionally  interpreted  according  to  Table  5-35.  Any  slave  that  detects  an 
uncorrectable  line  error  on  the  Data  or  CT  lines  shall  post  NAK  on  the  second 
cycle  after  the  cycle  to  which  the  error  applies.  During  Vie.  any  module  that 
defects  an  uncorrectable  line  error  on  the  Data  or  CT  lines  shall  post  MAK  on 
the  second  cycle  after  the  cycle  to  which  the  error  applies.  The  device 
should  be  notified  of  lino  errors.  During  messages,  the  error  shall  be  logged 
I  in  the  Acknowledge  word  by  setting  the  'Uncorrectable  Line  Error'  bit  to  one 
(refor  to  "5. 2. 3. 3.1  Single  Slave  Acknowledge.**). 
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Table  5-35.  Interpretation  and  Response  for  Uncorrectoble  Invalid  Symbols 


SIGNAL  LINE  GROUP 


Cycle  Type 


Cycle  Type 
(during  HO) 


Bus  Request 


Acknowledge  Sat 


Acknowledge  Set 
(during  Vie) 


Data  lines 
(during  Vie) 


Data  linos 
(during  Multi-slave 
acknowledgement ) 


(during  HO) 


Data  lines 
(during  header, 
except  HO) 


INTERPRETATION  AND  RESPONSE 


If  Wait  is  not  allowed:  No  Uait. 

If  Uait  is  allowed:  Uait  assarted  on  first 
cycle  of  detected  error  and  No  Uait 
asserted  on  remaining  contiguous 
error  cycles. 


Scheduled  Cycle  Type  (per 
defined  sequences). 


No  slave  ID  match. 


No  Bus  Request  asserted. 


Assume  NAK  posted. 


If  not  the  winner  of  vie,  set  master 
priority  unknown.  Should  notify  device. 


If  a  contender,  assume  that 
redundant  bits  which  disagree 
are  both  asserted. 

If  not  e  contender,  set  master  priority 
unknown . 

If  not  the  winner  of  vie, 
set  master  priority  unknown. 


For  redundant  bits  which  disagree,  no 
acknowledgement  for  corresponding 
module. 


Slaves  shall,  discard  header 
words,  take  no  action  based  on  header 
words,  set  the  Acknowledge  Word  AWT  field 
to  00,  set  the  S  field  to  1  and  become 
not  selected  after  Header  Acknowledge 
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5. 3. 9. 3  Sequence  Errors. 

Each  Bus  Interface  shall  detect  any  arror  that  causes  a  violation  in  the 
protocol  syntax  (sequence  definitions).  During  message  sequences*  errors 
I  shall  be  logged  in  the  Acknowledge  word  by  setting  the  'Sequence  Error  'bit  to 
I  one  (refer  to  "5. 2. 3. 3.1  Single  Slave  Acknowledge.").  The  device  should  be 
notified  of  detected  errors. 

5.3. 9. 3.1  Cycle  Type  Sequence  Errors. 

Every  Bus  Interface  shall  differentiate  each  bus  cycle  as  belonging  to 
one  of  the  bus  states  listed  in  Table  5-8.  Each  slave  in  a  sequence  shall 
determine  if  the  C^ele  Type*  as  indicated  by  the  CT  lines,  follows  a  legal 
sequence  as  defined  under  "5,2  GENERAL  REQUIREMENTS.."  The  differentiation 
of  legal  and  illegal  cycle  type  sequences  shall  he  by  comparing  the  set  of  bus 
states  that  are  defined  os  scheduled  states  for  the  current  sequence  to  the 
actual  sequence  of  symbols  received  on  the  CT  lines.  Table  5-36  shows  the 
required  response  of  a  slave  to  received  CT  symbols  (top  row)  verses  scheduled 
bus  states  (left  column).  Definitions  of  the  required  responses  are  given  in 
Table  5-37. 
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Table  5-37-  Cycle  Type  Deviation  Response  Definitions 


- 

Proceed  with  normal  operation. 

error 

Respond  to  Cycle  Type  sequence  error  as  defined  in 
"5. 3. 9. 3.1  Cycle  Type  Sequence  Errors" 

1 

Monitor  vie  process  (too  late  to  contend). 

2 

Ignore  CT  symbol,  expect  Z  cycle 

3 

Suspend  message;  refer  to  "5. 3. 5.1  Suspend.." 

4 

Expect  I  cycle  ( End-Of-Tanure) .  Set  master  priority  =  unknown. 

5 

Abort  message;  refer  to  "5. 3.5.2  Abort.." 

During  Vie*  a  Bus  Interface  that  detects  an  illegal  CT  sequence  shall 
post  NAK  on  the  AS  lines  two  cycles  after  each  occurrence  of  the  illegal  Cycle 
Type.  Modules  which  do  not  win  the  Vie  sequence  shall  set  master  priority 
unknown  as  described  in  *5. 3. 3.1  Vie  Sequence.." 

If  a  Cycle  Type  other  than  HO  is  received  os  the  next  Cycle  Type  follow¬ 
ing  completion  of  a  message  sequence.  Vie  or  Abort;  each  module  shall  assume 
that  no  HWA  has  been  transmitted  and,  therefore,  there  is  no  match  for  that 
module’s  slave  ID. 


A  Bus  Interface  that  is  a  Slave  in  a  sequence  and  has  detected  that  the 
Cycle  Type  symbols  hove  not  followed  a  legal  sequence  shall  post  HAH  for  every 
such  occurrence.  The  NAK  shall  be  posted  on  the  second  cycle  after  the  cycle 
that  deviated  from  the  legal  sequence.  If  the  illegal  sequence  leads  to  a 
condition  in  which  the  modulo  cannot  determine,  with  certainty,  that  the  mod¬ 
ule  should  a  Slave,  the  Sub  Interface  shall  not  drive  any  line,  other  th«n 
Bus  Request,  when  legal  and  required,  until  n  valid  K0  or  Idle  cycla  is 
detected. 


5. 3. 9. 3. 2  Acknowledge  Set,  Ua i  t  and  Bus  Request  Sequence  Errors. 


Bus  Interfaces  shall  detect  Acknowledge  Set,  Unit  and  Bus  Request 
sequence  errors.  Responses  to  these  errors  shall  b»  as  defined  in  Table  5-38. 
Modules  shall  not  post  NAK  on  the  AS  lines  in  response  to  AS,  Uait  nor  Bus 
Request  sequence  errors. 
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Table  5-58.  Sequence  Error  Response 


SIGNAL  LINE  GROUP 

SEQUENCE  ERROR  RESPONSE 

Acknowledge  Set 

During  vie*  if  not  the  winner 
set  master  priority  unknown. 

Uait 

Assume  Uait  is  not  asserted. 

Bus  Request 

Assume  Bus  Request  is  not 
asserted. 

5 . 3 .  9 .  4  Semant  i  c  Errors  ■ 

3. 3. 9. 4.1  Header  Semantic  Errors. 

Each  Bus  Interface  shall  detect  any  error  in  information  transfer  that 
has  protocol  significance.  Table  5-39  lists  and  defines  the  errors  in  this 
category.  In  response  to  these  errors*  the  Bus  Interface  shall  post  NAK  on 
the  AS  lines  within  two  cycles  after  the  error  is  detected  and  not  later  than 
two  cycles  after  the  end  of  the  message  or  partial  message.  The  Bus  Interface 
shall  also  log  the  error  in  the  Acknowledge  Word  by  making  the  bit  named  in 
t  Table  5~39  a  logic  1.  The  device  should  be  notified  that  an  error  was 
detected. 
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Table  5-59.  Semantic  Errors 


SEMANTIC  ERROR 


ERROR  DEFINITION 


Protect 

('Protect  Error*  bit) 


A  Urite  operation  has  been  attempted  on  a 
write  protected  Bus  Interface  register. 


Command 

('Command  Error*  bit) 


Header  Word  A  has  been  received  with  a 
reserved  coda  in  the  AT  or  MSG  Type 
fields. 

OR 

Header  Uord  A  has  been  received  with  a 
broadcast  slave  ID  and  a  single  slave 
Message  Type. 

OR 

Header  Uord  A  has  been  received  and  the 
master’s  priority  is  unknown. 

OR 

A  Tenure  Pass  Message  Header  Uord  A  has  been 
received  with  bits  <7..5>  asserted  or  AT  not 
equal  to  000  or  F  asserted  or  Header  Uord  B 
bits  <4..Q>  are  not  equal  to  the  MID  in  HWA . 

*■»  r\ 

\JT\ 

A  Type  16  module  has  been  selected  and  the 
F  bit  in  HMA  is  equal  to  1. 

OR 

A  Bus  Interface  Message  Header  Uord  A 
has  been  received  with  F  asserted. 


Resource  not  Present 
('Resource  Hot 
Present  Error'  bit) 


A  resource  or  capability  has  been 
addressed  that  is  not  implemented. 

OR 

A  Tenure  Pass  Message  has  selected 
a  Feature  SO  module  as  the  slave. 

OR 

A  non-existent  or  reserved  Bus  Interface 
register  has  been  addressed. 


Dev i ce 

('Device  Error*  bit) 


Module's  device  has  detected  an  error 
attempting  to  perform  bus  related 
operation  during  the  current  message. 
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5.3. 9. 4.2  Header  And  Data  Acknowledge  Semantic  Errors. 


A  bus  master  Bus  Interface  shall  report  semantic  errors  in  the  Header 
and  Data  Acknowledge  Word  to  the  device.  The  semantic  errors  which  shall  be 
reported  era 

1.  the  Acknowledge  Mord  slave  MID  does  not  match  the  physical  slave  ID 
transmitted  in  Header  Mord  A, 

2.  the  Acknowledge  Word  Type  (AMT)  field  of  the  Acknowledge  Mord  is  not 
valid  for  the  current  Acknowledge  cycle. 

I  3.  a  Class  ED  master  module  receives  an  Acknowledge  word  with  the  "Cerrec- 

I  table  line  Error"  bit  set  to  logic  1  and 

I 

|  4.  an  Acknowledge  word  which  has  the  "Protect  Error"  bit  set  to  logic  1  is 
received  when  the  MSG  Type  specified  in  HMA  was  not  Bus  Interface 
Message. 


5. 3. 9. 5 


5. 3. 9. 5.1  On-Line  Testing. 


On-line  testing  of  the  Pl-bus  shall  be  accomplished  through  the  Error 
Detection  and/or  error  Correction  Capability  provided  by  tbs  standard 
sequences  and  protocol  defined  in  previous  sections  of  this  specification. 


5. 3. 9. 5. 2  Off-li ne  Tasti ng. 

Each  Bus  Interface  shall  be  capable  of  transmitting  and  receiving  arbi¬ 
trary  bit  patterns  on  all  signal  lines  of  the  bus  CD.  DC.  CT >  CTC.  A5>  W  end 
BR)  in  parallel.  Multiple  clock  cycles  may  be  used  to  establish  and  read  each 
pattern.  Control  and  coordination  of  this  test  shall  be  through  an  alternate 
path  independent  from  the  Pi-bus  under  test.  The  mechanism  that  coordinates 
the  test  should: 

1.  provide  the  line  patterns  to  the  Bus  Interface  transmitting  the  test 
pattern. 

2.  determine  when  the  transmit  pattern  is  stable. 

3.  read  thQ  received  patterns  from  the  receiving  Bus  Interfacets)  and 

4.  analyze  the  patterns  for  correctness. 

The  mechanism  that  controls  the  test  should  apply  patterns  that  guarantee 
detection  of  l)  a  failed  line  stuck  at  zero  or  one  and  2)  a  short  between  any 
two  lines  for  any  path  from  the  signal  line  latch  of  the  transmitting  Bus 
Interface  to  the  signal  line  latch  of  the  receiving  Bus  InterfaceC  a) . 

The  transmitting  Bus  Interface  shall  be  capable  of  being  placed  in  the 
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off-line  test  mode*  accepting  patterns  for  transmission  and  transmitting  the 
patterns.  Once  established,  test  patterns  shall  not  be  changed  until  a  change 
is  commanded  by  mechanism  that  coordinates  the  test. 

The  receiving  Bus  Interface,  when  in  the  off-line  test  mode,  shall  be 
capabla  of  being  commanded  to  clock  in  the  test  pattern  from  the  bus  and 
transfer  that  received  pattern  to  the  controlling  device. 
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1  SCOPE 

1.1  Scope-  This  speci  f  i  cat  i  on  establishes  the  electrical,  functional  and 
performance  requirements  for  the  set  of  signal  lines  that  constitute  the 
Test  and  Maintenance  feus  (TM-Bu»>. 


1.2  Purpose.  The  purpose  of  this  standard  is  to  establish  requirements  for 
the  TM-Bus  and  facilitate  interoperability  of  modules  which  use  the  TM-Bus. 

1.3  Intended  Application.  The  TM-Bus  is  intended  as  a  serial  path  for  test 
and  maintenance  control  and  data  information. 


2  APPLICABLE  DOCUMENTS 


2.1  Government  Documents.  The  following  documents  of  the  exact  issue  shown 
form  a  part  of  this  specification  to  the  extent  specified  herein.  In  the 
event  of  conflict  between  the  documents  referenced  herein  and  the  contents 
of  this  specification,  the  contents  of  this  specification  shall  be  consid¬ 
ered  a  superseding  requirement. 

•  VHSIC  Phase  2  INTEROPERABILITY  STANDARDS  Pi-Bus  SPECIFICATION 

2-2  Non-Government  Documents.  The  following  documents  of  the  exact  issue 
shown  form  a  part  of  this  specification  to  the  extent  specified  herein.  In 
the  event  of  conflict  between  the  documents  referenced  herein  and  the  con¬ 
tents  of  this  specification,  the  contents  of  this  specification  shall  be 
considered  a  superceding  requirement. 

•  None. 


3  DEFINITIONS 

The  definitions  listed  here  shall  apply  to  the  TM-bus  and  TM-bus  modules. 

2.1  Item  pef  <  n i t i on .  The  TM-bus  is  a  linear,  multi-drop  communications 
medium  which  transfO'rs  bit  serial  data  between  a  'MASTER'  module  and  up  to 
22  'SLAVE'  modules  residing  on  a  single  backplane. 

TM-bus  modules  implement  the  TM-bus  protocol  and  meet  all  requirements  of 
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asserted 


backplane 


broadcast 


bus  MASTER 


The  logic  1  state  of  a  bus  signal  line. 
The  least  positive  of  the  two  states  of  a 
bus  signal  line. 

A  motherboard  comprising  wiring  for  the  bus 
end  connectors  to  the  modules  attached  to 
the  bus. 

A  mode  of  operation  where  the  bus  MASTER 
transmits  data  to  all  SLAVE  modules  during  a 
single  sequence. 

The  module  in  control  of  the  bus. 


contend 


devi ce 


header 


linear  ous 
message 


module 


When  a  bus  SLAVE  module(s)  is /are  actively 
vying  for  the  attention  of  the  bus  MASTER. 

The  portion  of  a  module,  excluding  the  bus 
interface,  which  does  the  application 
dependent  function  of  the  module. 

A  sequence  identifying  a  bus  command,  the 
SLAVES  participating  in  any  commanded 
sequence  and  additional  information  delimit¬ 
ing  the  scope  of  the  command. 

A  bus  with  a  single  shared  medium  segment. 

A  set  of  sequences  starting  with  a  header 
and  terminating  when  all  bus  actions  indi¬ 
cated  by  that  header  have  been  performed. 

An  entity  which  is  addressable  via  the  bus 
and  has  a  single  bus  connection. 


module  address 


A  jointer  which  uniquely  identifies  a  mod¬ 
ule 


multicast 


packet 


A  mode  of  operation  w f.ere  the  MASTER  may 
transmit  data  to  more  than  one  SLAVE  during 
a  single  sequence. 

A  unit  of  data  which  is  17  bits,  a  16  bit 
word  plus  1  parity  bit. 


rel ease 


The  action  of  ceasing  to  assert  a  logic  1 
on  a  bus  signal  lii.°  The  action  of  releas¬ 
ing  a  signal  line  produces  a  change  in  the 
state  of  the  signal  line  only  if  no  nodule 
is  asserting  that  signal. 
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released 


response 


sequence 


SLAVE 


sub-address 


transfer 


word 


The  logic  C  state  o-f  a  bus  signal  line  pro¬ 
duced  when  no  module  asserts  the  signal 
associated  with  that  line.  The  moru  posi¬ 
tive  of  the  two  states  of  a  bus  signal  line 
relative  to  the  0  Volt  logic  reference. 

A  set  of  sequences  sent  by  the  SLAVE  as  a 
result  of  a  message  being  sent  by  the 
MASTER. 

An  indivisible  transaction  comprising  a 
number  of  transfers  performing  one  intended 
function. 

A  module  which  does  not  have  control  of  the 
bus  but  which  is  selected  by  the  MASTER  to 
participate  in  a  sequence. 

A  pointer  to  elements  within  an  addressable 
module. 

A  set  of  elemental  operations  on  the  bus 
which  result  in  the  communication  of  bit 
serial  datum  units  between  the  current  bus 
MASTER  and  the  selected  SLAVECs).  A  serial 
datum  unit  is  1  bit.  See  sequence. 

An  ordered  set  of  16  bits  operated  on  as  a 
unit.  The  most  significant  bit  is  labeled 
bit  16  and  the  least  significant  bit  is 
labeled  bit  1. 


4  PHYSICAL  LAYER 


4.1  I nt r oduct i on .  The  physical  layer  of  the  TM-Bus  is  specified  herein. 
The  lines  required  to  implement  the  TM-Bus  are  defined,  the  electrical  char¬ 
acteristics  of  the  modules  and  backplane  are  specified  and  timing  defi¬ 
nitions  are  presented.  The  bus  interface  facilities  which  are  accessible  to 
a  bus  MASTER  over  the  bus  are  also  defined. 


4.2  L i ne  Def i ni t i on .  The  TM-Bus  signal,  clock  and  module  identification 
lines  are  defined  in  this  section. 


4.2.1  nomenclature.  Lines  shall  be  designated  by  name.  When  a  set  of 
related  bit*,  are  represented  by  the  same  name,  the  bits  within  the  set  shall 
be  differentiated  by  number  with  the  least  significant  bit  numbered  0.  All 
fields  shall  be  referred  to  by  their  bit  position  within  a  data  word  trans- 
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farrad  aver  the  TM-bus .  The  nomenclature  for  single  bit*  ahull  be  the  bit 
number  enclosed  in  <  >.  The  nomenclature  <m..n>  shall  be  the  abbreviation 
for  the  set  of  bits  m  to  n  inclusive,  where  m  and  n  are  the  most  and  least 
significant  bits  respectively. 


4.2.2  TM-Bus  Signal  Definition.  There  shall  be  four  «4)  signal  types  that 
make  up  the  TM-fius  as  shown  in  Figure  2  on  page  4.  All  bus  signals  shall 
use  negative  logic,  i.e.  the  logic  *1*  state  (or  asserted  state!  is  the  low¬ 
est  voltage  level  on  the  bus  and  the  logic  • 0 '  tor  released  state)  is  the 
higher  voltage  level  on  the  bus. 


4.2.2. 1  TM-Bus  CLOCK  Signal  Definition.  The  TM-Bus  CLOCK  signal  shall  be  a 
single  phase  clock.  The  Th  Bus  interface  shall  support  the  full  range  of 
clock  frequencies  from  zero  (0)  Hz  to  4.25  MHz.  All  control  and  data  trans¬ 
fer  operations  shall  be  synchronized  with  the  TM-Bus  CLOCK  signal.  All  data 
and  commands  shall  be  placed  on  the  TM-Bus  on  the  high  to  low  transition  of 
the  clock  and  latched-in  on  the  next  higr>  to  low  transition. 

4. 2. 2. 2  TM-hus  MASTER  DATA  Signal  Definition.  The  TM-Bus  MASTER  DAT  A  sig¬ 
nal  shall  be  •  single  un i -di r ect i ona 1  line  used  to  transmit  device 
addresses,  instruction  data,  and/or  scan  data  from  the  MASTER  to  the 
SLAVE ( s ) .  The  MASTER  DATA  line  is  also  used  in  conjunction  with  the  CONTROL 
line  to  indicate  bus  states  (see  Section  "5.2.1  TM-Bus  States"  on  page  9>. 

4.2. 2.3  TM-Bus  SIAVE  DATA  Signal  Definition.  The  TM-Bus  SLAVE  DATA  signal 
shall  be  used  to  transmit  acknowledgements,  data,  and/or  interrupts  from  the 
SLAVE(s)  to  the  MASTER.  The  TM-Bus  SLAVE  DATA  line  shall  support  a  uired- 
OR  configuration. 

4. 2. 2. 4  TM-Bus  CONTROL  Signal  Definition.  The  TM-Bus  CONTROL  signal  shall 
be  a  single  uni -di rect i onal  line  from  the  MASTER  to  the  SLAVES(s).  When  the 
CONTROL  line  is  asserted  the  bus  is  placed  in  the  DATA  TRANSFER  state.  When 
CONTROL  it  released,  the  bus  is  in  the  PAUSE  or  IDLE  state. 
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A. 2. 2.5  TM-Bus  Addressing.  Each  TM-Bus  SLAVE  is  addressed  by  an  eight  bit 
address  -field.  This  address  shall  be  sent  in  the  HEADER  packet  containing 
the  -five  (5)  bit  (nodule  address  tbits  <16..12>)  and  the  three  (3)  bit 
sub-address  (bits  <11. .9>),  (see  Figure  6  on  page  11). 

The  -five-bit  module  address  -field  in  the  HEADER  shall  be  compared  to  five 
Module  IDent i f i cat i on  (MID)  inputs  to  determine  if  the  SLAVE  is  being 
addressed.  As  a  minimum,  each  SLAVE  shall  also  have  a  Module  Identification 
Parity  (MIP)  input  that  shall  be  set  such  that  the  modulo  two  sum  of  the 
five  MID  inputs  and  the  MIP  input  equals  one  (1).  (Note:  the  asserted  state 
of  each  input  is  a  logical  one).  When  used  in  conjunction  with  the  VHSIC 
Phase  2  Pi-Bus,  it  is  recommended  that  each  TM-Bus  SLAVE  module  have  its  MID 
and  MIP  inputs  hardwired  to  the  backplane  of  the  TM-Bus  (see  section  "A. 2. 4 
Module  Identification”  of  the  Pi-Bus  Specification).  If  an  unr ecover abl e 
error  occurs  on  the  MID  inputs,  the  TM-Bus  SLAVE  shall  not  execute  any  coml 
mands  and  shall  release  the  SLAVE  DATA  line. 

Comparison  of  the  three  (3)  sub-address  bits  from  the  HEADER  packet  against 
Sub— address  IDent i f i cat i on  (SID)  inputs  is  optional. 

Module  addresses  *0*  through  *30’  have  a  maximum  of  eight  (8)  subaddresses. 
Address  '31'  is  limited  to  three  (3)  subaddresses  (*F8*,  *F9',  and  ’FA’  HEX) 
due  to  restrictions  of  broadcast  and  multicast  commands.  See  Section  "5.2.5 
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Broadcast  Capability"  on  page  1£  and  Section  "£ . 2 • S  Multicast  Capability”  on 
page  IS  for  details. 


4.S  ELECTRICAL  R EQU I R EhE NT S .  Electrical  characteristics  for  the  TM-Bus 
backplane  and  modules  shall  be  as  specified  in  the  most  recent  version  of 
the  VHSIC  Phase  2  PX-Bus  Specification,  Section  "4.3  ELECTRICAL 
REQUIREMENTS". 
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5  DATA  LINK  LAYER 


5.1  Introduct i on.  The  Test  and  Maintenance  Bus  (TM-Bus)  shall  be  the  chan¬ 
nel  for  control  and  data  information  flow  between  a  maintenance  controller 
and  modules  within  a  system.  The  module  in  control  of  the  TM-Bus  shall  be 
referred  to  as  the  MASTER  and  all  other  modules  on  the  TM-Bus  shall  be 
referred  to  as  SLAVES.  The  information  transferred  and  the  scheduling  of 
data  and  commands  is  system  dependent  and  is  not  addressed  in  this  specifi¬ 
cation.  Figure  3  on  page  £  summarizes  the  TM-Bus  design  parameters  and 
charact eristics. 


8? 

ivj 

t 

£ 


V: 

rj 
« 
a  a 

£~ 


s 


V. 


a 

o  Performance  Characteristics 

—  5.25  MHz  clock  (Typical) 

—  4  pin  bus  signals 

—  Synchronous  Operation 

—  Two  Data  Lines 

—  SLAVE  status  register 


o  Protocol  Character i st i cs 

S  reserved  address  bits 

32  module  addresses  (maximum) 

S  sub-addresses  per  module 
address 

Multi— drop  Configuration 
Interrupt  Capability 


Figure  3.  TM-Bus  Design  Parameters  and  Characteristics 


5.2  Qper at i on .  Messages  transmitted  by  the  MASTER  shall  consist  of  a  com¬ 
mand  HEADER  packet,  and  optional  DATA  packets.  If  required,  the  SLAVE  shall 
respond  by  acknowledging  the  command  and/or  transmitting  any  DATA  packets 
requested.  The  SLAVE  shall  only  transmit  packets  when  requested  to  do  so 
by  the  MASTER.  The  SLAVE  shall  indicate  interrupts  as  specified  in  Section 
"5.2.4  TM-Bus  Interrupts"  on  page  20.  All  data  shall  be  transmitted  MSB 
first. 

The  following  figures  and  paragraphs  describe  the  operation  of  the  four  line 
serial  TM-Bus  in  detail. 
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5.2.1  TH-Els  Stages.  There  *r«  iter  e  e  possible  bus  states  es  t h in 
Figure  4.  The  IDLE  state  indicates  that  date  shell  not  be 


CONTROL 

MASTER  DATA 

STATE 

0 

0 

IDLE/INTERRUPT  (End  of  Message  ( EQM ) ) 

0 

1 

PAUSE/INTERRUPT 

1 

0 

DATA  TRANSFER 

1 

1 

DATA  TRANSFER 

Figure  4.  TM-BUS  STATES 


transferred  over  the  bus  but  interrupts  from  the  SLAVES  ere  allowed  over  the 
SLAVE  data  line.  The  PAUSE  state  shall  be  used  between  packets  during  t» 
■■iaaa^v  transfer  to  *11  ww  SLAVE*  to  interrupt  inn  HASTES-  'The  !uaia  TRANSFER 
state  indicates  that  data  shall  be  transferred  over  the  MASTER  data  line  or 
the  SLAVE  data  line  or  both.  Figure  &  on  page  lb  shows  the  state  diagram 
for  the  TM-Bus. 


Packets  in  a  transmission  may 
states  (typically  from  0  to  5, 
ber>.  The  end  of  a  message 
state. 


b<;  separated  by  a  variable  number  of  PAUSE 
system  requirements  may  dictate  i>  higher  nun- 
shall  be  signified  by  *  return  to  the  IDLE 
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Figure  5.  TM-Bus  Stale  Diagram 
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5.2.2  Hessaoe/R esponse  Packet  Pescr i pt i ons .  All  messages  sent  by  the  MAS¬ 
TER  shall  consist  of  a  HEADER  and  up  to  256  DATA  packets.  Responses  (from 
the  SLAVE)  shall  consist  of  an  optional  ACKNOWLEDGE  packet  and/or  up  to  256 
DATA  packets.  To  allow  flexibility,  the  number  of  DATA  packets  contained  in 
a  response  is  determined  by  user  definable  commands  cwith  a  maximum  of  256). 


5. 2. 2.1  DATA  PACKETS.  The  DATA  packet  contains  sixteen  (16)  data  bits 
(bits  <16..1>>  and  one  packet  parity  bit  (bit  <0>>.  The  contents  and  format 
of  the  data  bits  are  not  specified.  Data  shall  be  sent  MSB  (bit  16)  first. 


5. 2. 2. 2  Packet  Parity.  Bit  0  of  each  packet  shall  contain  one  packet  pari¬ 
ty  bit.  The  parity  shall  be  odd  parity  such  that  the  modulo  2  sum  of  a  data 
packet  (bits  <16..0>>  =  1.  The  parity  bit  shall  be  transmitted  last  as  the 
LSB . 


5. 2. 2. 3  HEADER  Packets.  Figure  6  shows  the  format  for  the  HEADER  packet 
which  includes  the  SLAVE  address  and  command  fields.  The  SLAVE  address 
field  is  eight  (8)  bits  in  length  (bits  <1G..9>>.  The  SLAVE  command  field 
is  seven  (7)  bits  in  length  (bits  <S..2>>.  The  ACKNOWLEDGE  REQUEST  field  is 
one  bit  in  length  (Bit  <1>>. 


The  standard 
page  24.  If 
asserted,  the 
packet  parity 


commands  are  defined  in  Section  "5.3  Commend  Definitions 
the  ACKNOWLEDGE  REQUEST  bit  <bit  <1>  of  the  HEADER) 
SLAVE  shall  respond  with  an  ACKNOWLEDGE  packet.  Bit  0  is 
bit. 


on 
i  s 
the 
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5. 2. 2. 4  ACKNOWLEDGE  Packets.  Figure  7  cn  page  12  shows  the  ■format  tor  the 
ACKNOWLEDGE  packet  which  includes  the  SLAVE  address  and  status  fields.  The 
SLAVE  address  field  is  eight  (8)  bits  in  length  (bits  <1£..9>>  and  contains 
the  address  of  the  responding  SLAVE.  The  status  field  is  also  eight  (8> 
bits  in  length  (bits  <8..1>)  and  contains  the  data  residing  in  the  SLAVE 
Status  Register,  lit  0  is  the  parity  bit. 


MSB  LSB 

(IS)  (9>  (8)  (1>  (0> 


(8) 

(8) 

(1  > 

SLAVE  ADDRESS 

SLAVE  STATUS  REGISTER 

PARITY 

(MODULE  AND  SUB- 

CONTENTS 

BIT 

ADDRESS) 

Figure  7.  ACKNOWLEDGE  PACKET 


5.2.3  Message  Protocol.  Message  transmissions  from  the  MASTER  to  the  SLAVE 
shall  be  as  shown  in  Figure  8.  A  message  transmission  shall  begin  by  moving 
from  the  IDLE  state  to  the  DATA  TRANSFER  state  (the  CONTROL  line  being 
asserted)  at  which  time  the  HEADER  packet  is  transmitted.  The  CONTROL  line 
shall  be  asserted  for  the  duration  of  each  packet  transmission.  The 
IDLE/EOM  state  shall  be  indicated  at  the  end  of  a  a  transmission  by  releas¬ 
ing  the  CONTROL  line  (MASTER  DATA  line  shall  be  released  in  the  IDLE/EOM 
state).  The  PAUSE  state  shall  be  indicated  between  packets  by  releasing  the 
CONTROL  line  (with  MASTER  DATA  line  asserted).  If  the  message  is  more  than 
one  packet  in  length,  then  the  CONTROL  line  shall  be  asserted  during  each 
additional  packet  transmission.  Optional  PAUSE  states  are  permitted  between 
packets  within  a  single  message.  The  maximum  number  of  PAUSE  states  shall 
be  determined  by  system  requi rement s ,  and  the  minimum  number  of  PAUSE  states 
is  xero. 
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Figure  «.  MESSAGE  PROTOCOL 


E.2.4  Res^on^e _ Protocol  .  All  states  on  the  SLAVE  DATA  line  including 

PAUSE,  IDLE.  and  packet  transmissions,  shall  be  synchronous  to  the  MASTER 
DATA  end  CONTROL  lines  with  a  two  clock  cycle  delay  a s  shown  in  Figure  9  on 
page  14.  Tins  r"eley  is  required  so  that  the  SLAVE  can  receive  and  react  to 
state  transitions  on  the  MASTER  DATA  and  CONTROL  lines.  The  SLAVE  DATA  line 
shall  begin  a  packet  transmission  with  the  CONTROL  line  asserted,  following 
receipt  of  a  HEADER  packet  as  shown  in  Figure  10  and  Figure  11  with  the  two 
cycle  delay  described  above.  The  Flowchart  of  Figure  12  on  page  17  shows 
the  flow  diagram  of  the  SLAVE  response. 
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If  the  ACKNOWLEDGE  Ml  1b  asserted  In  the  HEADER,  the  addressed  SLAVE  shall 
respond  with  in  ACKNOWLEDGE  packet  during  the  next  packet  transmission  peri¬ 
od.  After  the  optional  ACKNOWLEDGE  packet,  any  DATA  packets  required  by  the 
decoded  command  shall  be  transmitted  as  shown  In  Figure  11  on  page  IS.  The 
SLAVES  shall  net  respond  with  an  acknowledge  during  broadcast  or  multicast 
operations. 

If  the  message  to  the  SLAVE  contains  DATA  packets  as  shown  in  Figure  11  and 
the  acknowledge  bit  is  asserted,  then  the  SLAVE  shall  respond  by  sending  an 
ACKNOWLEDGE  packet  during  the  next  period  that  data  may  be  sent  ever  the 
SLAVE  DATA  line.  After  the  optional  ACKNOWLEDGE  packet,  any  DATA  packets 
required  by  the  command  shall  be  transmitted  as  shown. 

As  shown  in  Figure  11  on  page  IS  data  transfer  may  occur  simultaneously  on 
the  MASTER  DATA  line  and  the  SLAVE  DATA  line.  This  simultaneous  transfer  is 
dependent  on  the  command  received  by  the  SLAVE.  None  of  the  standard  com- 
■■•>11  require  simultaneous  transmissions. 

Interrupt  Handling  protocol  is  described  in  Section  "5.2.9  TM-Bus 
Contention"  on  page  21. 
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Figure  10.  SLAVE  RESPONSE  PROTOCOL  (A) 


C-19 


MASTER 

DATA 

HEADER 

DATA  1 

DATA 

SLAVE 

DATA 


DATA  1 


CONTROL 


-OH- 


n*>  i  tx 

DATA 

HEADER 

DATA  1 

SLAVE 

DATA 


ACKNOWLEDGE 


DATA  1 


CONTROL 


=  DON'T  CARE 


Figure  11.  SLAVE  RESPONSE  PROTOCOL 


C-20 


..  .*  xnit  « 


TM-bus  Specification 


Versi on  1.2 


5.2.5  Broadcast  Capability.  The  MASTER  shall  have  the  capability  to  broad¬ 
cast  to  all  SLAVES  by  setting  the  SLAVE  address  field  equal  to  ( *  FB  *  HEX). 
All  SLAVES  shall  recognize  this  address  in  addition  to  their  normal  module 
address  and/or  sub-address.  SLAVES  shall  ndicate  correct  receipt  of  a 
|  broadcast  command  (HEADER  packet)  by  asserting  the  Broadcast/Mul t i cast 
Received  bit  in  the  SLAVE  status  register.  The  Broadcast/Multicast  Received 
bit  shall  be  released  if  the  broadcast  command  uas  not  received  correctly  or 
the  SLAVE  Mas  busy  during  a  broadcast  operation,  such  that  it  could  not  exe¬ 
cute  the  TM-Bus  command.  See  sections  "5.3.1  Reset  SLAVE"  on  page  24, 
"5.5.3  Read  Status  Register"  on  page  24,  and  "5.6  TM-Bus  Error  Handling"  on 
page  27  !  for  further  discussions  of  the  broadcast/multicast  received  bit. 
Note  that  a  SLAVE  shall  have  the  capability  to  execute  the  standard  commands 
regardless  of  their  busy  state.  SLAVES  shall  assert  the  SLAVE  Busy  or  the 
Bus  Error  bit  in  the  SLAVE  status  register  if  a  broadcast  command  is  not 
|  received  properly.  SLAVES  shall  not  transmit  any  response  packets  over  the 
SLAVE  DATA  line  in  response  to  broadcast  operations  except  during  CONTEND 

I  commands.  SLAVES  may  issue  interrupts  during  a  broadcast  operation  (see 
section  "5.2. t  TM-Bus  Interrupts"  on  page  20). 

5.2.6  Multicast  Capability.  The  MASTER  shall  have  the  capability  to  multi¬ 
cast  to  any  number  of  SLAVES.  SLAVES  shall  belong  to  one  of  four  multicast 
groups  (DO.  01.  10,  11).  SLAVES  Shall  be  selected  for  these  groups  by  send¬ 
ing  one  of  the  four  Multicast  Select  commands.  The  SLAVE  status  register 
shall  maintain  two  bits  indicating  which  of  the  four  possible  multicast 
groups  the  SLAVE  belongs  to.  When  the  TM-Bus  is  reset,  via  a  Reset  SLAVE 
command,  SLAVES  are  set  to  membership  in  group  *00*.  A  SLAVE  shall  remain  a 
member  of  a  multicast  group  until  a  Multicast  Select  Command  (or  Reset  SLAVE 
command)  is  sent  to  change  the  SLAVE  to  another  group. 

Four  addresses  shall  be  recognized  by  SLAVES  as  valid  multicast  addresses. 
Address  ( *FC*  Hex),  ( ’FD’  HEX),  ('FE*  HEX)  and  ('FF'  HEX)  shall  be  used  for 
multicast  groups  *00*,  *01*,  *10’,  and  *11*  respect  i  vely.  SLAVES  shall 

|  indicate  correct  receipt  of  a  multicast  command  (HEADER  packet)  by  asserting 
the  Broadcast/Multicast  Received  bit  in  the  SLAVE  status  register.  The 
Broadcast/Multicast  Received  bit  shall  be  released  if  the  multicast  command 
was  not  received  correctly  or  the  SLAVE  was  busy  during  a  multicast  opera¬ 
tion.  such  that  it  could  not  execute  the  TM-Bus  command.  See  sections 
"5.3.1  Reset  SLAVE"  on  page  24,  "5.3.3  Read  Status  Register”  on  page  24,  and 
"5.6  TM-Bus  Error  Handling"  on  page  27 'for  further  discussions  of  the  broad¬ 
cast/multicast  received  bit.  Note  that  a  SLAVE  shall  have  the  capability  to 
execute  the  standard  commands  regardless  of  their  busy  state.  SLAVES  shall 
assert  the  SLAVE  Busy  or  the  Bus  Error  bit  in  the  SLAVE  status  register  if  a 

I  multicast  command  is  not  received  properly.  SLAVES  shal!  not  transmit  any 
packets  over  the  SLAVE  DATA  line  in  response  to  multicast  operations,  except 
during  Contend  commands.  See  section  "5.3  Command  Definitions"  on  page  24 
}  for  details  of  Multicast  Select  commands.  SLAVES  may  issue  interrupts  dur- 
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ing  a  aulticast  operation  (aae  section  "5. 2. ft  TM-Bus  Interrupts"  on  page 

20). 


*.2.7  TM-Rus  SLAVE  Status  Register.  Each  SLAVE  shall  have  a  SLAVE  Status 
Register  described  in  Figure  IS  on  page  20.  All  bits  in  the  status  register 
shall  be  considered  active  uhen  asserted.  The  Bus  Error, 
ftroadcast/Mult i cast  Received,  and  Event  Occurrence  bits  shall  be  reset  to  a 
logic  *0*  (released)  uhen  the  SLAVE'S  Status  Register  is  read  by  a  Read  Sta¬ 
tus  Register  coaanand.  Resetting  the  Reserved  bit  in  the  Status  Register 
shall  be  optional  uhen  this  cesnand  is  executed.  The  Bus  Error,  Broadcast 
Received,  and  Event  Occurrence  bits  shall  be  reset  to  a  released  state  uhen 
a  SLAVE  uins  a  contend  sequence.  Resetting  the  Reserved  bit  in  the  Status 
Register  shall  be  optional  uhen  a  SLAVE  uins  a  contend  sequence. 
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Bit 

Name 

Heaning  When  Active 

8 (MSB ) 

Available  for  user  defined  status. 
May  be  used  for  address  extension. 

7 

SLAVE  Busy 

Indicates  that  the  application  side 
of  the  TM-Bus  Interface  is  busy. 

8 

Event  Occurrence 

Indicates  that  an  error  condition 
or  other  predefined  condition 
exi sts . 

5 

Broadcast/ 

Multicast  Received 

Indicates  that  the  last  Broadcast/ 
Multicast  command  was  properly 
recei ved. 

8 

Bus  Error 

Indicates  that  a  parity  error 
or  an  illegal  command  has  been 
detected  by  the  SLAVE. 

3 

Multicast  Select 

Bit  1 

Indicates  SLAVE  multicast  select 

Mode. 

2 

Multicast  Select 

Bit  0 

Indicates  SLAVE  multicast  select 

Mode. 

1CLSB) 

Interrupt  Enabled 

Indicates  whether  the  SLAVE 
may  send  an  interrupt. 

igure  13.  SLAVE  Status  Register 


5.2.8  TM-Bus  Interrupts.  Any  SLAVE  may  signal  an  interrupt  to  the  MASTER 
by  asserting  the  SLAVE  DATA  line  for  one  clock  period/cycle  during^  the  PAUSE 
or  IDLE  states,  (when  interrupts  are  enabled)  as  shown  in  Figure  14.  On 
receiving  an  interrupt,  the  MASTER  may  service  that  interrupt  by  issuing  a 
•CONTEND  for  bus'  command,  checking  the  error  status  bits,  and  taking  appro¬ 
priate  action. 


The  SLAVE  shall  send  an  interrupt  out  over  the  SLAVE  DATA  line  when  the 
Event  Occurrence  or  Bus  Error  bits  are  asserted.  The  SLAVE  shall  consider 
the  interrupt  condition  serviced  when  the  SLAVE  wins  a  contend  sequence  or 
the  MASTER  issues  a  Read  Status  Register  command  to  that  SLAVE.  The  SLAVE 
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•hall  continue  to  land  t he  interrupt  for  one  clock  period  after  all  subse¬ 
quent  contend  sequences,  that  the  SLAVE  does  not  Min,  until  the  interrupt  is 
serviced.  All  interrupts  shall  be  sent  only  during  periods  that  interrupts 
•re  valid  on  the  bus. 

If  the  SLAVE  Susy  bit  is  asserted  during  data  transfers  <lua  State  S3)  after 
the  optional  ACKNOHLECE  packet  is  transferred,  the  SLAVE  shall  send  an 
interrupt  over  the  bus. 

Any  SLAVE  that  is  currently  addressed  shall  have  the  ability  to  interrupt 
during  PAUSE  states  within  a  message.  An  active  SLAVE'S  interrupt  capabili¬ 
ty  shall  override  the  DISABLE  INTERRUPT  command.  The  SLAVE  shall  go  back  to 
the  state  selected  by  the  last  DISABLE  or  ENABLE  INTERRUPT  COMMAND  following 
completion  of  a  bus  transaction. 


rriUTim 
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2  cycle  delay 

<—>l 

DATA  j 

< - >  | 
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l<— > 

2 

cycle  Interrupt 

2 
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delay 

Permi tt  ed 

Figure  14.  INTERRUPT 

TIMING 

5.2.9  TM-Bus  Contention.  i  hen  the  CONTEND  for  bus  command  is  issued,  any 
number  of  SLAVEs  may  then  CONTEND  for  the  bus  by  simultaneously  transmitting 
their  ACKNOWLEDGE  packet  which  Includes  the  eight  (B>  bit  slave  address. 
SLAVES  shall  participate  in  the  CONTEND  command  only  when  they  have  a  prede¬ 
fined  event  occur  isuch  as  an  error  condition,  see  Section  "5.2.B  TM-Bus 
Interrupts"  on  page  20)  that  caused  or  would  cause  the  SLAVE  to  send  an 
Interrupt  to  the  MASTER.  SLAVES  shall  not  CONTEND  for  the  bus  if  their 
interrupt  has  been  disabled.  During  the  transmission  of  this  packet,  the 
SLAVE  shall  'listen*  to  the  SLAVE  DATA  line  and  inhibit  data  transmission  if 
a  higher  priority  address  is  ’heard'.  The  highest  SLAVE  address  shall  have 
the  highest  priority. 
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The  CONTEND  sequence  requires  two  clock  cycles  tor  the  presentation  ot  each 
SLAVE  ACKNOWLEDGE  bit,  whereby  the  SLAVES  transmit  their  9  ..  th 

address  bit  tirst.  then  -listen-  to  the  bus  tor  a  higher  address.  H  the 

hi  qher  address  is  not  -heard-,  then  a  SLAVE  shall  continue  to  H**™* te ly 
. . .  UK.  US  b„  suave  *eKH°HL»«  P.CV.S  w. 

been  placed  on  the  bus  (in  S2  clock  cycles)  and  one  bit  of  Parity  in  the 

»3rd  cycle,  or  until  a  higher  address  is  -heard’  on  the  bus  (as  shown 

Figure  15). 


C-26 


PRELIMINARY 


Tli-bus  Specification 


Version  1. 


CONTROL 


MASTER 

DATA 


HEADER 

(CONTEND  CMD) 


SLAVE 

DATA 


SLAVE  CONTEND  (33  clocks) 


CLOCK 


CONTROL 


SLAVE 

DATA 


BIT  16  BIT  15  BIT  14 


IT  — J 


TRANSMIT  — J  • - — - * —  LISTEN 


Figure  15.  CONTEND  SEQUENCE 


in-bus  specification 


Version  1.2 


5*3  Command  Definitions.  The  HEADER  commands  thoun  In  Figure  16  on  page 
26  are  defined  below.  There  shall  be  7  bits  allowing  127  S-LAVE  commands. 
Commands  0  through  15  shall  be  standard  or  reserved  commands  and  the  remain¬ 
der  shall  be  user  defined  commands.  The  command  (’7F*  HEX)  with  the 
ACKNOWLEDGE  REQUEST  bit  asserted  shall  be  an  illegal  command  to  all  SLAVES. 
If  the  *7F *  command  is  detected  by  a  SLAVE,  with  the  ACKNOWLEDGE  REQUEST  bit 
asserted,  then  the  SLAVE  shall  set  the  Bus  Error  bit  in  the  SLAVE  status 
register.  SLAVES  shall  execute  all  the  commands  defined  below  regardless  of 
the  state  of  the  BUSY  bit  in  the  SLAVE  status  register.  The  results  of  the 
following  commands  shall  be  reflected  in  the  returned  ACKNOWLEDGE  packet  (if 
ACKNOWLEDGE  has  been  requested)  except  for  the  Read  Status  command,  see  Sec¬ 
tion  "5.3.3  Read  Status  Register"  on  page  24. 


5.3.1  Reset  SLAVE.  This  command  shall  bring  the  TM-Bus  SLAVE(s)  to  an 
error— free  quiescent  state  and  resets  all  internal  registers,  counters,  and 
buffers  to  a  known  initial  state,  such  that  the  SLAVE  is  capable  of  receiv¬ 
ing  and  executing  commands.  When  a  SLAVE  receives  the  Reset  command,  all  of 
the  SLAVE  Status  Register  bits  shall  be  reset  to  a  released  state,  the 
SLAVE'S  multicast  select  group  mode  shall  be  reset  to  *00’,  and  SLAVE  inter¬ 
rupts  shall  be  disabled. 

A  broadcast  or  multicast  reset  command  shall  set  the  Broadcast /Mul t i cast 
Received  bit. 


5-3.2  Initialize  Module.  The  application  side  of  the  module  shall  be  ini¬ 
tialized  by  resetting  or  setting  required  registers  to  a  pre-defined  state. 


5.3.3  Read  Status  Register.  Upon  the  receipt  of  a  NON-broadcast/mul t i cast 
read  status  command,  the  SLAVE  shall  return  the  ACKNOWLEDGE  packet  which 
includes  the  current  eight  (8)  bit  SLAVE  Status  Register  contents.  This 
command  shall  then  reset  the  Bus  Error,  Event  Occurrence  ,  and  Broadcast 
Received  bits  to  the  released  state.  Resetting  the  User  Defined  bit  in  the 
SLAVE  Status  register  shall  be  optional. 

If  a  broadcast/multicast  read  status  command  is  received,  the  SLAVE  shall 
not  transmit  any  response  over  the  SLAVE  DATA  line.  The  Bus  Error,  Event 
Occurrence,  and  Broadcast  Received  bits  shall  be  reset  to  the  released 
state.  Resetting  the  User  Defined  bit  in  the  SLAVE  Status  Register  shall  be 
opt i onal . 


5.3.4  CONTEND  for  Bus.  This  command  shall  cause  all  SLAVEs  with  a  bit 
requiring  a  SLAVE  interrupt  asserted  within  the  SLAVE  Status  Word,  to  CON¬ 
TEND  for  the  bus  as  described  in  Section  "5.2.9  TM-Bus  Contention"  on  page 
21  . 
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5.3.5  Enabl a  I nt  errupt .  When  thia  command  la  received,  the  SLAVE  ahall  be 
allowed  to  interrupt  during  IDLE  or  PAUSE  atatea.  The  Interrupt  Enable  bit 
ahall  be  aet  in  the  SLAVE  status  register. 


5.3.6  pi&able  Interrupt.  When  this  command  is  received,  the  SLAVE  inter¬ 
rupt  capability  ahall  be  disabled.  The  Interrupt  Enable  bit  in  the  SLAVE 
status  register  shall  be  reset  to  a  released  state. 


ft 


5.1.7  Multicast  Select  0.  When  this  command  is  received,  the  SLAVE  shall 
be  placed  in  multicast  group  8  and  the  SLAVE  Status  Register  Multicast 
Select  bits  ahall  be  set  to  *00*.  This  ahall  enable  the  SLAVE  to  respond  to 
command  headers  Mlth  an  address  field  equal  to  CFC  HEX). 


5.1.8  Multicast  Select  1.  When  this  command  is  received,  the  SLAVE  shall 
be  placed  in  multicast  group  1  and  the  SLAVE  Status  Register  Multicast 
Select  bits  ahall  be  aet  to  *01*.  This  shall  enable  the  SLAVE  to  respond  to 
command  headers  with  an  address  field  equal  to  ('Kb*  HEX). 


5.3.3  Multicast  Select  2.  When  this  command  is  received,  the  SLAVE  shall 
be  pieced  in  multicast  group  2  and  the  SLAVE  Status  Register  Multicast 
Select  bits  shall  be  set  to  *10’.  This  shall  enable  the  SLAVE  to  respond  to 
command  headers  with  an  address  field  equal  to  <*FE’  HEX). 


£.3.10  Multicast  Select  3.  When  this  command  is  received,  the  SLAVE  shall 
be  placed  in  multicast  group  3  and  the  SLAVE  Status  Register  Multicast 
Select  bits  shall  be  set  to  'll*.  This  shall  enable  the  SLAVE  to  respond  to 
command  headers  Mith  an  address  field  equal  to  f*FF'  HEX). 
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Command  Field 

Command 

(MSB)  (LSB  > 

(8)  (2) 

0000000 

READ  STATUS 

' 0000001 

INITIALIZE  MODULE 

0000010 

RESET  SLAVE 

0000011 

CONTEND  FOR  BUS 

0000100 

MULTICAST  SELECT  0 

0000101 

MULTICAST  SELECT  1 

0000110 

MULTICAST  SELECT  2 

0000111 

MULTICAST  SELECT  3 

0001000 

ENABLE  INTERRUPT 

0001001 

DISABLE  INTERRUPT 

0001010 

RESERVED 

0001011 

RESERVED 

0001100 

RESERVED 

0001101 

RESERVED 

00011.0 

RESERVED 

0001111 

RESERVED 

Figure  16.  Standard  Commands 


5.4  TM-Bus  Synchronization/Initialization.  The  bus  shall  be  initialized 
when  both  the  MASTER  DATA  and  CONTROL  lines  are  simultaneously  released, 
■forcing  the  bus  into  the  IDLE  state.  All  SLAVES  on  the  bus  shall  then  be 
capable  of  transactions  over  the  bus.  If  desired,  the  command  ’Reset  SLAVE’ 
may  then  be  broadcast  to  bring  all  bus  lines  and  SLAVES  to  an  error-free 
quiescent  state.  When  a  SLAVE  receives  the  Reset  command,  all  of  the  SLAVE 
Status  Register  bits  are  reset,  its  multicast  select  mode  will  be  reset  to 
*00',  and  SLAVE  interrupts  will  be  disabled. 

A  broadcast  or  multicast  reset  command  shall  set  the  Broadcast/Mul t i cast 
Received  bit. 

5.5  TM-Bus  Mastership.  The  TM-Bus  shall  have  single  MASTER  operations. 
This  specification  shall  not  preclude  the  ability  for  systems  to  have  more 
than  one  MASTER  and  a  method  to  switch  mastership  of  the  bus  independent  of 
the  four  signal  lines  defined  in  this  specification. 
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5.6  TM-Bus  Error  Handling.  If  n  parity  error  is  detected  in  a  HEADER  pack¬ 
et.  the  SLAVE  shall  not  execute  the  command  and  shell  set  the  Bus  Error  bit 
in  the  SLAVE  status  register  end  signal  an  interrupt  m%  described  in  Section 
”5.2.6  TM-Bus  Interrupts'"  en  page  20.  When  a  parity  error  is  detected  by 
the  addressed  SLAVE  while  receiving  DATA  packets,  the  SLAVE  shall  set  the 
Bus  Error  bit  in  the  SLAVE'S  Status  Register  and  signal  an  interrupt  as 
described  in  Section  ”5.2.6  TM-Bus  Interrupts”  on  page  20. 

Stuck— et-0  bus  conditions  are  detected  by  the  odd  packet  parity  scheme  as 
described  in  Section  ”£.2.2.2  Packet  Parity"  en  pcge  11.  Stuck-at-1  bus 
conditions  shall  be  detected  as  an  illegal  command  as  doscribed  in  Section 
"5.3  Command  Definitions”  on  page  24. 

To  insure  error  free  reception  during  broadcast  or  multicast,  the  read  sta¬ 
tus  register  command  should  be  broadcast  or  multicast  first  to  clear  each 
SLAVE'S  broadcast/multicast  received  bit.  After  the  data  or  command  is 
broadcasted  or  multicasted,  the  broadcast/multicast  received  bit  should  be 
checked  by  reading  the  status  register  of  each  SLAVE  one  at  a  time. 


5.7  TM-Bus  Testing.  On-line  testing  of  the  bus  is  performed  as  a  result  of 
its  normal  operation.  Off-line  or  power — up  testing  may  be  accomplished 
through  the  use  of  bus  exercise  routines  and  bus  urap/hand-shak i ng  tests. 
The  MASTER  shall  be  able  to  send  bad  parity  or  set  any  SLAVE'S  Event  Occur-' 
rence  bit  and  chock  for  proper  SLAVE  response  utilizing  user  definable  com¬ 
mands  for  test  flexibility. 
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6  NOTES 

Any  comments  should  be  submitted  to: 
J.r.  Letellier 

Space  and  Warfare  Systems  Command 
Code  SI 4 

Washington.  D.C.  20363-5100 
phone  <202)  692-0701 
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ROM 

- 

End  of  Message 

Hx 

- 

Hertz 

LSB 

- 

Least  Significant  Bit 

HHx 

- 

Megahertz,  1  million  cycles  per  second 

n  A 

- 

Mi lli amperes,  1  thousandth  of  an  Ampen 

HID 

- 

Module  Identification 

HIP 

- 

Module  Identification  Parity 

MSB 

- 

Host  Significant  Bit 

nh 

- 

Nanohenry,  1  billionth  of  a  Henry 

ns 

- 

Nanosecond,  1  billionth  of  a  Second 

PF 

- 

Picofarad,  1  trillionth  of  a  Farad 

YBD 

_ 

To  Be  Defined 

TM-Bus 
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PREFACE 


Following  publication  of  this  specification,  a  High  Speed  Data  Bus 
Critical  Design  Review  of  Protocol  Definition  was  held  at  Wright-Patterson 
Air  Force  Base  on  13  January  1987.  The  following  list  of  planned  changes 
to  the  PAVE  PILLAR  High  Speed  Data  Bus  System  Specification  have  resulted 
due  to  that  review  and  later  interface  meetings  with  the  VHSIC  1750A  Com¬ 
puter  contractors.  These  planned  changes  also  reflect  an  attempt  to  bring 
the  specification  closer  to  that  of  the  SAE  AE-9B  Linear  Token  Passing 
Bus.  A  revised  High  Speed  Data  Bus  System  Specification  incorporating 
these  changes  will  be  available  in  March  1987. 

1.  INITIALIZATION  -  Method  has  been  changed  to  the  new  method  proposed 
by  Lockheed-Georgia .  This  is  necessary  to  reduce  the  chance  of  more 
than  one  terminal  attempting  to  take  control  of  the  bus. 

2.  MEDIA/COUPLER  -  Specification  of  media  characteristics  (e.g.,  fiber 
size)  will  be  relocated  to  appendices  (one  each  lOOum,  200um,  coax). 
Minimum  and  maximum  loss  will  be  specified. 

3.  PREAMBLE  -  Sixteen  (16)  bits.  Not  sent  between  concatenated  mes¬ 
sages  . 

A.  MESSAGE/FRAME  FORMATS  -  Changes  will  be  made  to  agree  more  closely 
with  SAE.  Unique  types  will  be  defined  but  not  required. 

5.  TIMERS  -  Exhaustive  message  class  deleted.  Section  will  be  rewrit¬ 
ten  for  better  understanding. 

6.  RETRIES  OF  TOKEN  PASS  -  Change  to  choice  of  0  or  1 ,  default  1. 

7.  ERROR  STATUS/STATISTICS  -  Change  to  follow  SAE  set  as  required, 
others  as  defined  by  31  October  86  specification  will  remain  defined, 
but  will  be  optional. 

8.  REALTIME  CLOCK  -  Change  name  to  "Reference  Timer."  Reduce  accuracy 
requirement  to  10E-4  (.01%),  increase  update  rate  to  bOrnS,  elim¬ 
inate  drift  rate  compensation  requirement. 

9.  TERMINOLOGY  -  An  attempt  will  be  made  to  agree  with  the  terminology 
used  by  the  SAE. 

10.  LOOPBACK  MESSAGE  -  The  Frame  Control  (FC)  field  will  be  changed  to 
indicate  "This  is  a  loopback  message”  to  prevent  infinite  loopback. 

11.  TOPOLOGY  MAP  -  This  proposed  change  would  simplify  the  imple¬ 
mentation  by  reducing  the  memory  required. 
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HIGH  SPEED  BUS  SYSTEM  SPECIFICATION 


1.  SCOPE 

This  specification  defines  performance,  design,  and  development 
requirements  for  a  High  Speed  Data  Bus  (HSDB)  data  communications 
system.  The  HSDB  shall  provide  a  real  time  communications  network  of  a 
maximum  of  64  terminals  with  addressing  growth  to  allow  future 
expansion  to  127  terminals.  Terminals  may  be  separated  by  a  maximum  of 
three  hundred  feet. 

2.  APPLICABLE  DOCUMENTS 

The  following  documents  of  the  issue  in  effect  on  26  September  1983,  or 
as  noted  below,  form  a  part  of  this  specification  to  the  extent 
specified  herein. 

2 . 1  Government  documents 

MIL-E-5400T  Electronic  Equipment,  Aerospace,  General 

Specification  For 

DOD-D-IOOOB  Drawings,  Engineering  and  Associated  Lists, 

Military  Specif ications  For 

2.2  Non -government  documents 

a.  IEEE-STD-802  Local  Area  Networks 


3.  REQUIREMENTS 

3.1  System  Definition 


The  HSDB  system  shall  provide  high  quality  data  communications 
among  a  network  of  user  terminals  at  a  bit  rate  of  50  Mbps.  The  HSDB 
shall  support  two  forms  of  media,  coaxial  cable  or  fiber  optic.  A  form 
of  token  passing  protocol  shall  normally  govern  access  to  the  network 


3,1.1  General  Description 

The  HSDB  network  shall  consist  of  a  set  of  user  terminals 
connected  to  a  common  media  as  illustrated  by  figure  1.  The  media 
shall  be  either  coaxial  cable  (wire)  or  fiber  optic  (FO)  for  any 
specific  network.  Between  two  and  sixty-four  user  terminals  shall 
connect  to  the  media  using  stub  Interconnect  of  the  type  compatible 
with  the  media.  Each  user  terminal  shall  also  connect  to  one  or  more 
users.  Each  terminal  shall  perform  the  functions  of  the  Media  Access 
Control  (MAC)  layer  and  the  Physical  (PHY)  layer  as  described  in  IEEE- 
STD-802.  This  shall,  allow  the  network  to  appear  transparent  to  the 
user  process. 
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A  form  of  token  passing  protocol  r.h&l.  1  be  used  to  perform  the 
management  functions  of  the  network.  The  token  controls  the  right  of 
access  to  the  media;  the  terminal  which  holds  (possesses)  the  token  has 
momentary  singular  control  over  the  network.  The  token  is  passed  from 
terminal  to  terminal  in  .a  deterministic  fashion  forming  a  logical  ring. 
Maintenance  functions  within  each  terminal  provide  for  initialization 
of  the  logical  ring,  lost:  token  recovery,  addition  of  stations  while 
the  network,  is  in.  operation,  and  general  network  monitoring. 

3 . 1 . 1 , 1  Convent! ons 


Several  conventions  are  followed  throughout;  this  document. 
These  are  described  below: 

a.  Numbering  of  Bits:  Digital  data  fields:  are  labeled 
using  the  convention  of  bit  #0  as  most  significant:  bit 
and  bit  #n  as  least  significant  bit. 

b.  Transmission  Sequence .:  Lower  numbered  bits  to  be 
transmitted  on  the  network  are  sent  first. 

3.1.2  Mission 

The  HSDB  shall  be  a  general  purpose  digital  communication 
network  and  shall  be  usable  in  ground  bfi.sed,.  shipboard,  and  aircraft; 
applications  within  the.  environmental  and  performance  constraints 
described  herein. 

3.1.3  Threat  (not  applicable) 

3.1.4  System  D  i.agr  ,mus 

HSDB  systems  shall  be  implemented  using  a  single  media  form, 
either  coaxial  cable  of  F0. 


3 . 1 . 4 . 1  Coaxial  Medi a  Topology 


Networks  implemented  using  coaxial  cable  media  anal  1  use  a 


n  rt/i  n  -r* 


vtt't  <■«.  1  , 
*■ 


i 


2r&'»-r3C 
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loaded  using  a  resistive  termination  at  each  extremity.  A  bi¬ 
directional  bus  coupler  shall  be  used  to  tap  the  bus  for  each 
terminal..  Dedicated  transmit  (IX)  and  Receiver  (Rtf.)  coaxial  stubs 
shall  connect  between  the  terminal  and  the  coupler.  A  TX/kX 
turnaround  stub  between  the  terminal  and  the  coupler  shall  decouple 
the  transmit  port  from  the  bus  unless  the  terminal  is  transmitting. 
Signal  amplitude  and  loss  values  are  shown  for  a  64  terminal  network . 


3, 1.4. 2  Fiber  Optic  Media  Topology 

Networks  implemented  using  FO  media  shall  use  a  passive  star 
topology  as  illustrated  by  figure  2b.  /V  single  centralized  star 
coupler  shall  provide  transmit  and  receive  access  t:o  each  terminal. 
Dedicated  TX  and  RX  F0  stubs  shall  connect  between  the  terminal  and 
the  coupler.  Signal  amplitude  and  loss  values  are  shown  for  a  64 
terminal  network. 
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3,1.5  Interface  Definition 

The  interface  between  the  terminal  and  the  user  process  shall 
be  identical  for  both  coaxial  and  F0  implementations  of  the  HSDB.  The 
interface  between  the  terminal  and  the  media  layer  and  within  the  media 
layer,  shall  be  implementation  unique. 

3 . 1 . 5 . 1  Terminal/User  Interface 

The  functional  interface  between  the  terminal  and  the  user 
shall  consist  of  a  set  of  4  data  transaction  units. 

a)  TX  Unit  -  The  TX  Unit  (TXU)  shall  be  comprised  of  data 
to  be  sent  from  the  terminal  to  one  or  more  other 
terminals  in  the  network. 

b)  RX  Unit  -  The  RX  Unit  (RXU)  shall  consist  of  data 
received  by  the  terminal  which  is  addressed  to  itself, 
and  which  contains  no  detected  errors. 

c)  Terminal  Management  Unit  -  Hie  Terminal  Management  Unit 
(TMU)  shall  consist  of  instructions  from  the  user  to  the 
terminal  to  set  the  operating  mode  of  the  terminal, 
request  transmission  of  data,  or  request 
network/tertainal  maintenance  information. 

d)  Terminal  Status  Unit.  -  The  Terminal  Status  Unit  (TSU) 
shall  consist  of  information  from  the  terminal  to  the 
user  to  indicate  receipt  of  a  message  from  the  network 
or  to  respond  to  a  request  for  terminal  or  network 
status  information. 

The  electrical,  physical,  and  format  description  of  this 
interface  is  beyond  the  scope  of  this  document,  The  information 
content  shall,  however,  be  consistent  with  the  requirements  of  this 
document . 

3. 1.5. 1.1  Transmission  Class  of  Service 

The  terminal  shall  support  two  classes  of  service  as  defined 
below.  Terminals  shall  operate  using  exhaustive  class  of  service 
unless  priority  class  is  enabled  following  initialization  of  the 
network. 

a.  Exhaustive:  The  terminal  shall  transmit  messages  to 
maximally  utilize  the  token  hold  time  each  time  the  token 
is  held,  within  the  constraints  of  the  token  hold  timer. 
All  messages  shall  be  scheduled  at  PO  level  independent 
of  the  priority  level  under  which  they  were  placed  in  the 
queue.  The  scheduling  algorithm  shall  be  first-in-first- 
out  (FIFO). 

b.  Multiple  level  priority:  The  terminal  shall  transmit 
all  messages  held  in  queue  within  the  constraints  of  the 
token  rotation  timers  and  the  token  hold  timer.  The 
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scheduling  algorithm  shall  be  FIFO  within  each  priority 
level . 

3. 1.5. 1.1.1  Data  Transmit  Transaction  Sequence 

The  sequence  of  transactions  between  the  user  and  the 
terminal  for  initiation  of  a  data  transmit  operation  shall  be  as 
described  in  Table  I . 


TABLE  I 

TRANSMIT  OPERATION 


TRANSACTION 

m 

USER 

TERM 

DESCRIPTION 

i. 

TMU 

---> 

:Request  to  send,  block  size,  class 

of  service,  destination,  subaddress 

2. 

< - 

TSU 

: Buffer  available/busy, 
destination  off-line 

3. 

TXU 

- > 

:Data 

4. 

TMU 

---> 

:Confirm  buffer  filled,  abort 

5. 

<--- 

TSU 

:Acknowledge  data  sent  (and  ack  If 
requested) 

A  compatible  methodology  for  Pi-Bus  interface  is  described  in  section 

2.0. 

3. 1.5. 1.1. 2  Transmit  Block  Size 

The  terminal  shall  contain  sufficient  local  storage  to  accept 
a  single  message  of  4096  words  from  the  user  during  a  single  transfer. 
Multiple  smaller  messages  may  share  the  transmit  block  at  the 
discretion  of  the  user.  Each  message  shall  be  characterized  by  its 
unique  class  of  service^ 

3. 1.5. 1.2  Receive  Operation 

Data  received  from  the  bus  shall  be  transferred  to  the  user 
at  a  rate  controlled  by  the  user.  The  terminal  shall  be  capable  of 
buffering  any  munber  of  consecutive  messages  from  the  bus  within  the 
constraints  of  the  terminal  buffer  siz-s.  As  a  minimum,  the  buffer 
shall  accommodate  a  single  message  of  4096  words  or  multiple  messages 
of  that  equivalent  size.  If  all  receive  buffers  are  full  when  a  new 
message  Is  received,  the  new  message  shall  be  dropped  arid  the  terminal 
shall  continue  normal  operation. 

3. 1.5. 1.2.1  Data  Receive  Transaction  Sequence 

Hie  sequence  of  transactions  required  between  terminal  and 
user  for  Initiation  of  a  data  received  operation  shall  be  as  described 
in  Table  11. 
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TABLE  II 

RECEIVE  OPERATION 


TRANSACTION 

m 

USER 

TERM 

DESCRIPTION 

i. 

<--- 

TSU 

:Data  block  size,  location  of  buffer 

source,  class  of  service 

2. 

RXU 

< - 

:Data 

3. 

TMU 

- > 

Confirmation  (free  buffer), 

location  of  buffer 


3. 1.5. 1,3  Status  Request  Transaction  Sequence 

The  sequence  of  transactions  required  between  terminal  and 
user  for  initiation  of  a  status  reporting  operation  shall  be  as 
described  in  Table  III. 

TABLE  III 

STATUS  REPORTING  OPERATION 
SEQ  USER  TERM  DESCRIPTION 
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b.  Bit  Rate 

c.  Modulation  Type 

d.  Minimum  Signal 

e.  Maximum  Signal 

f .  Impedance 

3 . 1 . 5 . 2 . 3  TX  Switch  Interface 

The  TX  switch  interface 
which  the  bus  coupler  disconnects 
mainline . 

a.  Connector  Type 

b.  Voltage  output  (TX) 

c.  Voltage  output  (RX) 

d.  Switching  Time 


3.1. 5.2,4  Bus  Mainline  Interface 


50Mbps  +25KHz 
Manchester  II 

0.025Vp-p  (50MHz  component) 
0.270Vpp  (50MHz  component) 
50  ohms  +  2  ohms 


shal  1  provide  the  means  by 
the  TIL  interface  from  the  BUS 


As  defined  by  applicable  critical 
item  specification 
11.0  +4,0Vdc  into  50  ohms 
-5.0  +0.5V  into  open  circuitry 
-2.5  +0-2Vdc  into  50  ohms 
-  TX  state  shall  be  asserted  and 
stable  within  100ns 


The  bus  mainline  interface  shall  provide  the  means  by  which 
the  bus  interconnects  between  adjacent  couplers. 


a. 

Connector  Type 

TNG  (female  polarity  on  coupler) 

b. 

Power  Level 

-  3  OVn-n  rri  4  fiVn - n 

component) 

MHz 

c. 

Impedance 

50  ohms  +  1.25  ohms  at 
and  50MHz 

25MHz 

3 . 1 . 5 . 2 . 5  Waveform 


The  critical  characteristics  of  the  waveform  shall  be  the 
wave  front  detection  period  including  the  embedded  state  transition 
points  and  their  spacing  (in  time).  As  shown  in  figure  3a,  a  wavefront 
detection  period  is  defined  within  any  5ns  segment  during  which: 


a.  The  first  Ins  period  (zone  A)  exhibits  a  minimum  rate 
of  change  of  2mv/ns, 

b.  The  following  4ns  period  (zone  B)  exhibits  the  same 
polarity  and  is  continuous. 


3. 1.5. 2. 5.1  Receiver  Waveform 


3. 1.5. 2. 5. 1.1  Amp 1 i tude  Change 

The  amplitude  of  the  waveform  during  Zone  B  of  the  wavefront 
detection  period  shall  be  between  10.5mv  and  300mv. 


3. 1.5. 2. 5. 1.2  Maximum  Signal 

The  maximum  signal,  including  overshoot  and  other  waveform 
anomalies  shall  be  not  more  than  500mv. 
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3, 1.5. 2. 5. 1.3  Timing 

The  period  between  adjacent  state  transition  points  of  the 
waveform  shall  be  either  10ns  +lns  or  20ns  +lns  for  valid  manehester 
logic  symbols.  The  period  between  adjacent  state  transition  points 
shall  be  30ns  +lns  for  the  special  symbols  reserved  for  message 
delimiting  (ref  3. 2. 1.1). 

3. 1.5. 2. 5. 2  Transmitter  Waveform 

3. 1.5. 2. 5. 2.1  Amplitude 

The  peak-to-peak  amplitude  of  the  smoothed  equivalent 
waveform  shall  be  15V  +1V  into  50  ohms. 

3. 1.5. 2. 5. 2. 2  Ripple  and  Droop 

The  total  ripple  and  droop  component  shall  be  less  than  10% 
of  the  peak-to-peak  amplitude  of  the  smoothed  equivalent  waveform. 

3. 1.5. 2. 5. 2. 3  Timing 

The  period  between  adjacent  state  transition  points  shall  be 
either  10ns  +lns  or  20ns  +lns  for  valid  manehester  logic  Eymbols.  The 
period  between  adjacent  state  transition  points  shall  be  30ns  +lns  for 
the  special  symbols  reserved  for  message  delimiting  (ref  3. 2. 1.1). 

3. 1.5. 2. 5. 2. 4  Risetime/Falltime 

The  time  between  the  10%  points  and  the  90%  points  (and 
inverse)  shall  be  between  2ns  and  6  ns. 

3. 1.5. 3  F0  Terminal/Media  Interface 

The  interface  between  a  FO  type  user  terminal  and  the  media 
shall  consist  of  two  discrete  interfaces.  In  the  case  of  terminals 
with  dual  redundant  HSDE  ports,  each  port  shall  be  independent  and 
shall  meet  the  requirements  stated.  In  the  case  of  single  port 
terminals,  the  "A"  bus  shall  be  the  active  port  and  the  "B"  bus  shall 
not  be  implemented. 

3. 1.5. 3.1  TX  Interface 

The  TX  interface  shall  be  used  to  place  properly  modulated 
and  formatted  data  packets  on  the  bus  under  control  of  the  user 
terminal . 


a. 

Connector  Type 

As  defined  by  applicable  critical 
item  specification 

b. 

Wavelength 

850  run 

c . 

Power  Lever  (peak) 

400uw-pk 

d. 

Modulation  Type 

Binary  Manchester 

e . 

Fiber  Type 

100/140  micron,  semi -graded  index 

f. 

Numerical  Aperture 

-  0.29 
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3. 1.5. 3. 2  RX  Interface 


The  RX  interface  shall  be  used  to  recover  properly  modulated 
and  formatted  data  packets  from  the  bus. 


a.  Connsctor  Type 

b.  Wavelength 

c.  Modulation  Type 

d.  Fiber  Type 

e .  Numerical  Aperture 


As  defined  by  applicable  critical 
item  specification 
850  nm 

Binary  Manchester 

100/140  Micron,  semi -graded  index 

0.29 


3.1..  5.3.3  Javeform 


The  waveform  as  monitored  at  any  transmitter  or  receiver  port 
shall  meet  the  following  requirements  (reference  figure  4) . 

3. 1.5. 3. 3.1  Risetime 

Risetime  of  the  optical  pulse  shall  be  less  than  4  ns.  No 
anomalies  shall  be  present  during  the  risetime  portion  of  the  pulse. 

3 . 1 . 5 . 3 . 3 . 2  Falltime 

Falltime  of  the  optical  pulse  shall  be  less  than  4  ns.  No 
anomalies  shall  be  present  during  the  falltime  portion  of  the  pulse. 

3 . 1 . 5 . 3 . 3 . 3  Ripple/Droop 

The  difference  in  peak  amplitude  between  any  two  pulses  in  a 
message  shall  be  less  than  1.5db. 

3. 1.5. 3. 3. 4  On/Off  Ratio 

The  ratio  between  the  100%  point  of  an  optical  pulse  and  the 
0%  point  of  segments  of  the  waveform  shall  be  no  less  than  45db, 

3. 1.5. 3. 3. 5  Symmetry 

The  ratio  of  ontime  to  bit  period  shall  be  0.5  +0.05  (for 
valid  manchester  symbols). 

3.1.6  Government  Furnished  Property  List  (not  applicable) 

3.1.7  Operational  and  Organizational  Concepts 

The  HSDB  systam  shall  be  a  general  purpose  50Mbps  digital  data 
communications  network  and  shall  be  usable  in  ground  based,  shipboard, 
and  aircraft  applications  requiring  127  or  fewer  terminals  within  the 
environmental  and  performance  envelope  described  herein. 

3.2  Characteristics 
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3.2.1  Performance  Characteristics 

The  HSDB  shall  encompass  the  functions  of  the  media  layer 
(MED),  physical  layer  (PHY)  and  Media  Access  Control  (MAC)  layer  of  a 
network  as  described  in  IEEE-STD-802.  Figure  5  illustrates  the 
relationship  between  IEEE-STD-802  functions  and  HSDB  elements.  The  MED 
shall  be  implemented  in  the  form  of  coaxial  cable  and  couplers  for 
coaxial  type  implementations  and  in  the  form  of  fiber  optic  cable  and  a 
coupler  for  FO  type  implementations.  The  PHY  and  the  MAC  shall  be 
implemented  in  the  form  of  electronic  circuitry  in  the  HSDB  terminal. 

A  unique  PHY  design  shall  be  required  for  each  type  terminal,  coaxial 
or  FO.  The  MAC  shall  be  identical  for  either  implementation. 

3. 2. 1.1  Message  Format 


Messages  placed  on  the  bus  shall  conform  to  the  message 
format  described  below  including  the  size  and  location  of  all 
transaction  data  unit  fields  and  the  hierarchy  of  functions  within  data 
units.  Four  message  formats  shall  be  supported  by  the  HSDB,  token 
messages,  data  messages,  maintenance  messages,  and  alternate  control 
messages.  The  sequence  of  transaction  data  units  comprising  a  data 
message  is  described  in  Table  IV. 


TABLE  IV 

BUS  MESSAGE  COMPOSITION 
SEQUENCE  TRANSACTION  DATA  UNIT 


SIZE 


1 

2 

3 

4 

5 

6 

7 

8 

7  a/8  a 


9 


Preamble  (PRE) 

Start  Delimiter  (SD) 

Frame  Control  (FC) 

Destination  Address  (DA) 

Source  Address  (SA) 

Word  Count  (WC) 

Data 

Frame  Check  Sequence  (FCS) 
Additional  data  fields  and  FCS 
fields  may  be  appended  prior 
to  ED  for  messages  longer 
than  256  words 
End  Delimiter  (ED) 


8  bits 
4  bit  times 
8  bits 

8  bits  or  16  bits 
8  bits 

16  bits  or  0  bits 
0  to  256  words 
16  bits 


4  bit  times 


A  valid  abort  sequence,  PRE  +  SD  -K - >  +  ED  +  ED,  shall  be 

defined.  Any  message  length  shall  be  allowed  between  the  SD  and  ED 
fields,  up  to  a  maximum  of  65,856  bits.  The  abort  sequence  shall  be 
sent  under  certain  conditions  following  detection  of  a  transmitter 
error  in  order  to  allow  receiving  terminals  to  differentiate  from 
network  and  receiver  errors. 

It  shall  be  possible  to  concatenate  messages  within  a  single 
transaction.  In  this  case,  the  messages  shall  be  delimited  by  an  ED  + 
SD  sequence  without  Intervening  PRE  or  intermessage  gap. 

The  sequence  of  transaction  data  units  comprising  a  token 
message  shall  be  PRE  +  SD  +  FC  +  DA  +  SA  +  FCS  +  ED.  The  composition 


D-  20 


SPA  90099001A 
16  January  1987 


\ 

HIGHER 

LAYERS  * 


1 


LOGICAL  LINK 

CONTROL  (LLC) 

MEDIA  ACCESS 

CONTROL  (MAC) 

PHYSICAL 

LAYER  (PHY) 

y 

MEDIA 

LAYER  (MED) 

y 

HSD8  USER 


CONTROLLER/ 
INTERFACE 
UNIT  (CIU) 


TRANSMIT/ 
RECEIVE 
UNIT  (TRU) 


HSB  MEDIA 


HSDB 
f“  TERMINAL 


FIGURE  5 


HSDB  FUNCTIONAL  PARTITIONING 


SPA  90099001 A 
16  January  1987 

of  each  field  Is  described  in  Table  IV.  The  DA  for  a  token  message 
shall  always  be  8  bits  in  length.  The  sequence  of  transaction  data 
units  comprising  a  data  message  shall  be  PRE  +  SD  +  FC  +  DA  +  SA  +  WC  + 
data  +  FCS  +  ED.  The  DA  for  a  data  message  shall  always  be  16  bits  in 
length.  The  sequence  of  transaction  data  units  comprising  a 
maintenance  message  shall  be  PRE  +  SD  +  FC  +  DA  +  SA  +  <WC  +  data  +> 

FCS  +  ED.  The  DA  for  a  maintenance  message  shall  always  be  8  bits  in 
length. 

3. 2. 1.1.1  Preamble 

The  PRE  field  pattern  shall  precede  each  transmitted 
message.  It  shall  consist  of  8  bits  of  logic  1  symbols. 

3. 2. 1.1. 2  Start  Delimiter 

The  SD  field  shall  consist  of  the  4  bit  time  sequence  of 
valid  and  invalid  symbols  as  indicated  in  Table  V. 

TABLE  V 

START  DELIMITER 

Symbol 

Valid  logic  "0" 

Invalid  symbol  -  no  transition  from  bit  #1 
Invalid  symbol  -  complement  of  bit  #2 
Valid  logic  "0" 

3. 2. 1.1. 3  Frame  Control 


Bit  Time 

1 

2 

3 

4 


The  FC  field  shall  be  used  to  define  the  message  type.  The 
first  two  bits  shall  define  the  message  format: 

Bit  # 

0  1 


00  —  Token  management  message 

01  —  Data  message 

10  -  Terminal  maintenance  message 

11  -  Alternate  control  message  (reserved) 

3. 2. 1.1. 3.1  Token  Management  Message 

Bits  2  through  7  of  a  token  management  message  shall  be 
encoded  as  defined  by  Table  VI. 


Bit  # 

2  3  4  5  6  7 


TABLE  VI 

TOKEN  MANAGEMENT  FC  CONSTRUCT 

Definition  Message  Construct 


0  0  0  0  0  0 
0  0  0  0  0  1 
0  0  0  0  1  0 


Illegal 
Solicit  Entry 
Set  Successor 


DA  +  SA  +  FCS 
DA  +  SA  +  CS  +  FCS 
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Bit  # 

2  3  4  5  6  2 


TABLE  VI  (Cont'd) 

TOKEN  MANAGEMENT  FC  CONSTRUCT 


Definition 


Message  Construct 


0  0  0  0  1  1 

)  0  0  1  0  0 

0  0  0  1  0  1 

0  0  0  1  1  1 

0  0  1  0  0  1 

0  10  10  1 

10  0  10  1 
10  0  110 
through 
111111 


Pass  Token 
Set  Predecessor 
Request  Entry 
Pass  Token,  Leave  net 
Solicit  Reentry 
Request  Reentry 
Claim  Token 


DA  +  SA  +  FCS 
DA  +  SA  +  CP  +  FCS 
DA  +  SA  +  FCS 
DA  +  SA  +  FCS 
DA  +  SA  +  FCS 
DA  +  SA  +  FCS 

Paragraph  3. 2. 1.4. 4. 1.6 


Reserved 


Where  CS  and  CP  are  the  8 -bit  current  successor  and  current 
predecessor  addresses. 


3. 2. 1.1. 3. 2  Data  Message 

Bits  2  through  7  of  a  data  message  shall  specify  requested 
class  of  response  and  priority  as  defined  by  Table  VII  and  Table  VIII. 


TABLE  VII 

DATA  FC  CONSTRUCT  -  CLASS  OF  RESPONSE 


Bit 
2  3 

# 

4 

Class  of  Response 

Message  Construct 

0  0 

0 

No  acknowledgment  requested 

DA  +  SA  +  WC  +  Data  +  FCS 

0  0 

1 

Reserved 

0  1 

0 

Reserved 

0  1 

1 

Reserved 

TABLE  VIII 

Data  FC  CONSTRUCT  -  PRIORITY 


Bit  # 

567  Priority 

000  Highest  Priority  (P0) 

001  Mid  Priority  (PI) 

010  Low  Priority  (P2) 

100  No  Priority  (P3) 

3. 2. 1.1. 3. 3  Maintenance  Message 

Bits  2  through  7  of  a  maintenance  message  shall  be  encoded  as 
defined  by  Table  IX.  Maintenance  messages  shall  be  scheduled  in  the 
transmit  queue  at  the  priority  level  described  by  Table  IX  unless 
explicitly  scheduled  at  a  different  level  by  the  user. 
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Bit  # 


2 

3 

4 

5 

6 

7 

Definition  Priority 

Mesi 

Lfi£ 

Cons truct 

0 

0 

0 

0 

0 

0 

RESET  (off-line) 

0 

DA 

i- 

SA 

+ 

FCS 

0 

0 

0 

0 

0 

1 

Set  maintenance  loopback 

2 

DA 

+ 

SA. 

4 

PCS' 

0 

0 

0 

0 

1 

0 

Disable  Maintenance  loopback 

2 

DA 

■(- 

SA 

+ 

FCS 

0 

0 

0 

0 

1 

1 

Loopback  message 

2 

DA 

-i- 

SA 

WC  4 

Data 

f 

FCS 

0 

0 

0 

1 

0 

0 

Set  topology  memory 

0 

DA 

4 

SA. 

+ 

WC  4 

Data 

4 

FCS 

0 

0 

0 

1 

0 

1 

Report  topology  memory 

3 

DA 

+ 

SA 

4- 

FCS 

0 

0 

0 

1 

1 

0 

Topology  message 

3 

DA 

+ 

SA 

+ 

WC  4 

Data 

"}* 

FCS 

0 

0 

0 

1 

1 

1 

Reserved 

0 

0 

1 

0 

0 

0 

Set  parameter (a) 

0 

DA 

4 

SA 

4 

WC  4 

Data 

4 

FCS 

0 

0 

1 

0 

0 

1 

Report  Parameter (s) 

3 

DA 

4 

SA 

4 

WC  4 

Data 

4 

FCS 

0 

0 

1 

0 

1 

0 

Parameter  message 

3 

DA 

+ 

SA 

+ 

WC  4 

Data 

4 

FCS 

0 

0 

1 

0 

1 

1 

Reserved 

0 

0 

1 

1 

0 

0 

Reserved 

0 

0 

1 

1 

0 

1 

Report  terminal  statistic(s) 

.3 

DA 

4 

SA 

4- 

WC 

Data 

4 

FCS 

0 

0 

1 

1 

1 

0 

Statistl.c(s)  report 

2 

DA 

-I- 

SA 

4- 

WC  4 

Data 

4 

FCS 

0 

0 

1 

1 

1 

1 

Reserved 

0 

1 

0 

0 

0 

0 

Reserved 

0 

1 

0 

0 

0 

1 

Set  Message  Filter 

0 

DA 

4 

SA 

4- 

WC  4 

data 

4 

FCS 

0 

1 

0 

0 

1 

0 

Report  Message  Filter 

3 

DA 

+ 

SA 

4 

PCS 

0 

1 

0 

0 

1 

1 

Message  Filter  Config.  msg. 

3 

DA 

+ 

SA 

+ 

WC  4- 

data 

4 

FCS 

0 

1 

0 

1 

0 

0 

Reserved 

0 

1 

0 

1 

0 

1 

Set  Realtime  Clock 

0 

DA 

+ 

SA 

+ 

WC  4 

data 

4- 

FCS 

0 

1 

0 

1 

1 

0 

Report  Realtime  Clock 

0 

DA 

-4- 

SA. 

+ 

PCS 

0 

1 

0 

1 

1 

1 

Realtime  Clock  Report 

0 

DA 

4- 

SA 

4- 

WC  4 

data 

4 

FCS 

0 

1 

1 

0 

0 

0 

Reserved 

0 

1 

1 

0 

0 

1 

Set  Redundant  Bus  Mode 

3 

DA 

4 

SA 

•f 

FCS 

0 

1 

1 

0 

1 

0 

Reset  Redundant  Bus  Mode 

2 

DA 

+ 

SA 

4 

FCS 

The  content  of  maintenance  messages  shall  conform  to  the 
construct  defined  in  subsequent  paragraphs.  In  all  cases,  the  SA  field 
shall  contain  the  terminal  address  (TA)  of  the  terminal  originating  the 
message  and  the  DA  field  shall  contain  the  terminal  address'  of  the 
terminal  to  which  the  message  is  directed. 

■i  .2 .  a.  .  a.  .  j  .  j.r  .ooupuacK.  nessage 

A  terminal  receiving  a  loopback  message,  when  loopback  mode 
is  enabled,  shall  queue  a  complementary  response  message  in  which  the 
SA  and  DA  fields  are  interchanged.  The  data  field  shall  be  unchanged. 
The  FCS  shall  be  recalculated  for  the  response  message. 

3. 2. 1.1. 3, 3. 2  SET  TOPOLOGY  MEMORY 

The  data  field  of  a  SET__TOPOLOCY_M EMORY  message  shall  consist, 
of  a  sequence  of  40  bit-records,  one  for  each  terminal  included  in  the 
topology . 
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Blt(s) 


0-7 

- 

Terminal  address 

8 

m 

Present  <■  "1"/Absent  -  "0" 

9 

- 

Online  -  "1M /Off line  -  "0" 

10 

- 

Timekeeper  —  "l"/Not  Timekeeper 

11 

— 

Reserved  (set  to  "0") 

12 

- 

TX  "A"  Port  Operational  - 

"1" 

13 

- 

TX  "B"  Port  Operational  - 

14 

- 

RX  "A"  Port  Operational  - 

"1" 

15 

- 

RX  rB"  Port  Operational  - 

1" 

16-23 

- 

Predecessor  Address  (PA) 

24-31 

- 

Successor  Address  (CS) 

32-39 

_ 

Reserved 

Should  the  message  contain  an  odd  number  of  records, 
additional  bits  of  logic  0  data  shall  be  appended  to  the  field 
sufficient  to  fill  it  to  a  length  evenly  divisible  by  16.  The  WC 
field  of  a  SET  TOPOLOGY  MEMORY  message  shall  define  the  count  of  16  bit 
frames  which  exist  within  the  data  field  rather  than  the  count  of  40 
bit  records. 

3. 2. 1.1. 3. 3. 3  TOPOLOGY  Message 

The  data  field  of  a  TOPOLOGY  message  shall  be  identical  to 
that  described  for  a  SET  TOPOLOGY  memory  message . 

3 . 2 . 1 . 1 . 3 . 3 . 4  SET  PARAMETER 


The  data  field  of  a  SET  PARAMETER  message  shall  consist  of  a 
sequence  of  24-bit  records,  1  for  each  parameter  to  be  set  as 
defined  by  Table  X.  Unused  bits  shall  be  0, 

TABLE  X 

PARAMETER  DESCRIPTORS 


Bit  Parameter 

01234567  Bits  8  through  23 


00000000 
00000001 
00000010 
00000011 
0  0  0  0  0  1  0  0 
0  0  0  0  0  1  0  1 
00000  1  10 
00000111 
00001000 
00001001 
00001010 
00001011 
through 

11111111 


Reserved 

Reserved 

RWT  value  (16-23) 
THT  value  (8-23) 
TRT_Pl  value  (8-23) 
TRT_P2  value  (8-23) 
TRT_P3  value  (8  23) 
RMT  value  (8-23) 

SET  value  (8-23) 
RLT  value  (20-23) 
NIT  value  (16-23) 
Reserved 


Reserved 


SPA  90099001A 
16  January  1987 

Bits  8  through  23  shall  contain  the  value  to  which  the 
parameter  is  to  be  set.  Should  the  message  contain  an  odd  number  of 
parameter  records,  additional  bits  of  logic  0  data  shall  be  appended  to 
the  data  field  sufficient  to  fill  it  to  a  length  evenly  divisible  by 
16.  The  WC  field  of  a  set  parameter  message  shall  define  the  count  of 
16 -bit  frames  which  exist  within  the  data  field  rather  than  the  count  j 

of  24 -bit  records. 

3. 2. 1.1. 3. 3. 5  REPORT  PARAMETER 

The  data  field  of  a  REPORT  PARAMETER  message  shall  consist  of 
a  sequence  of  8 -bit  records,  1  for  each  parameter  to  be  reported. 

Table  X  defines  the  relationship  between  parameter  and  data  content 
with  the  following  additions: 

0000  1011  Reserved 

0000  1111  Message  Filter  Size  Description 

Should  the  message  contain  an  odd  number  of  records,  additional  bits  of 
logic  0  data  shall  be  appended  to  the  field  sufficient  to  fill  it  to  a 
length  evenly  divisible  by  16.  The  WC  field  of  a  report  parameter 
message  shall  define  the  count  of  16 -bit  words  v?hich  exist  within  the 
data  field  rather  than  the  count  of  8 -bit  records. 

3. 2. 1.1. 3. 3. 6  PARAMETER  Message 

The  data  ad  WC  fields  of  a  PARAMETER  message  shall  be 
identical  to  that  described  for  a  SET  PARAMETER  message  with  the 
following  additions : 


0000  1011  Reserved 

0000  1111  Message  Filter  Size  Description  (20-23) 

3. 2. 1.1. 3. 3. 7  REPORT_TERMINAL_STATISTICS 

The  data  field  of  a  REPORT_TERMINAL_STATISTICS  message  shall 
consist  of  a  sequence  of  8  bit  records,  one  for  each  statistic  to 
be  reported.  Table  XI  defines  the  relationship  between  statistic  and 
data  content. 


TABLE  XI 

STATISTIC  DESCRIPTORS 

Bit 


0 

1 

2 

3 

4 

5 

6 

7 

Statistic 

0 

0 

0 

0 

0 

0 

0 

0 

Terminal  Status  Summary 

0 

0 

0 

0 

0 

0 

0 

1 

Number 

of 

P0  messages 

sent 

0 

0 

0 

0 

0 

0 

1 

0 

Number 

of 

P0  messages 

received 

0 

0 

0 

0 

0 

0 

1 

1 

Number 

of 

PI  messages 

sent 

0 

0 

0 

0 

0 

1 

0 

0 

Number 

of 

PI  messages 

received 

0 

0 

0 

0 

0 

1 

0 

1 

Number 

of 

P2  messages 

sent 

0 

0 

0 

0 

0 

1 

1 

0 

Number 

of 

P2  messages 

received 

0 

0 

0 

0 

0 

1 

1 

1 

Number 

of 

P3  messages 

sent 

0 

0 

0 

0 

1 

0 

0 

0 

Number 

of 

P3  messages 

received 

0 

0 

0 

0 

1 

0 

0 

1 

Number 

of 

tokens  received 
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TABLE  XI  (Cont'd) 
STATISTIC  DESCRIPTORS 

Bit 


0 

1 

2 

3 

4 

5 

6 

7 

Statistic 

0 

0 

0 

0 

1 

0 

1 

0 

NuE>h"r 

of 

tokens  viewed  on  net 

0 

0 

0 

0 

1 

0 

1 

1 

Average 

token  cycle  time  (usee) 

0 

0 

0 

0 

1 

1 

0 

0 

Maximum 

token  cycle  time  (usee) 

0 

0 

0 

0 

1 

1 

0 

1 

Average  transmission  delay  - 

PO 

(usee) 

0 

0 

0 

0 

1 

1 

1 

0 

Maximum 

transmission  delay  - 

P0 

(usee) 

0 

0 

0 

0 

1 

1 

1 

1 

Average  transmission  delay  - 

PI 

(usee ) 

0 

0 

0 

1 

0 

0 

0 

0 

Maximum 

transmission  delay  - 

PI 

(usee) 

0 

0 

0 

1 

0 

0 

0 

1 

Average 

transmission  delay  - 

P2 

(usee) 

0 

0 

0 

1 

0 

0 

1 

0 

Maximum 

transmission  delay  - 

P2 

(usee) 

0 

0 

0 

1 

0 

0 

1 

1 

Average 

transmission  delay  - 

P3 

(usee) 

0 

0 

0 

1 

0 

1 

0 

c 

Maximum 

i  transmission  delay  - 

P3 

(usee) 

0 

0 

0 

1 

0 

1 

0 

1 

Numbe  r 

of 

Data  errors 

0 

0 

0 

1 

0 

3. 

1 

0 

Humber 

of  RX  framing  errors 

0 

0 

0 

1 

0 

1 

1 

1 

Humber 

of 

RX  sync  errors 

0 

0 

0 

I 

1 

0 

0 

0 

Humber 

of 

RX  WC  errors 

0 

0 

0 

1 

1 

0 

0 

1 

Humber 

of 

bus  activity  error 

s 

0 

0 

0 

•v 

1 

0 

1 

0 

Humber 

of 

net  initialize  errors 

0 

0 

0 

l 

1 

0 

1 

1 

Humber 

of 

solicit  successor 

cycles 

0 

0 

0 

1 

1 

1 

0 

0 

Humber 

of 

claim  token  cycles 

0 

0 

0 

1 

1 

1 

0 

1 

Humber 

of 

lost  tokens  detected 

0 

0 

0 

1 

1 

1 

1 

0 

Humber 

of 

token  errors  detected 

0 

0 

0 

1 

1 

1 

1 

1 

Number 

of 

transmitter  errors 

0 

0 

1 

0 

0 

0 

0 

0 

Humber 

of 

receiver  errors 

O' 

0 

1 

0 

0 

0 

0 

1 

Number 

of 

token  hold  errors 

0 

0 

1 

0 

0 

0 

1 

0 

Realtime  clock  drift  rat* 

0 

0 

1 

0 

0 

0 

1. 

1 

Humber 

of 

abort  messages  detected 

0 

0 

1 

0 

0 

1 

0 

0 

through 

1 

1 

1 

l 

1 

1 

1 

1 

Reserved 

Should  the  message  contain  an  odd  number  of  records, 
additional  bits  of  logic  0  data  shall  be  appended  to  the  field 
sufficient  to  fill  it  to  e  length  evenly  divisible  by  lb.  The  WC  field 
of  a  HE  PORT _TERK I NAL  _STAT1 STI CS  message  shall  define  the  count  of  16- 
bit  word  which  exist  within  the  field  rather  than  the  count,  of  8-bit 
records . 

3. 2. 1.1. 3. 3.  (i  STATISTICS  REPORT 

The  data  field  of  a  STATISTICS  REPORT  message  shall  consist, 
of  a  sequence  of  24 -bit  records,  one  for  each  statistic  being 
reported.  Bits  0  through  7  shall  define  the  statistic  as  defined  in 
Table  XI.  With  the  exception  of  the  terminal  status  summary  report, 
bite  8  through  2.3  shall  contain  the  value  of  the  statistic.  Fields 
reporting  numeric  statistics  shall  be  organized  as  a  16  bit.  binary 
quantity  with  the  LSB  as  bit  23. 

The  Terminal  Status  Summary  report  shai 1  be  formatted  as 

shown : 


b-27 


Bit 

8  : 

Bit 

9,10  : 

Bit 

11,12: 

Bit 

13: 

Bit 

14: 

Bit 

15: 

Bit 

16: 

Bit 

17-23: 
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Bit  Summary  (0  -  failed/1  -  passed) 

Fx  Machine  Status  (IX  •»  Port  "A"  OK  :Xl  -  Port  "B"  OK) 
Tx  Machine  Status  (IX  -  Port  "A"  OK  :X1  -  Port  "B"  OK) 
APM  Status  (0  -*  failed/1  -  passed) 

UIM  Status  (0  -  failed/1  -  passed) 

Power  Status  (0  -  failed/1  -  passed) 

Topology  Memory  (0  —  initial  condx/1  -  operational) 
Reserved 


Should  the  message  contain  an  odd  number  of  records,  additional  bits 
of  logic  0  data  shall  be  appended  to  the  field  sufficient  to  fill 
it  to  a  length  evenly  divisible  by  16.  The  WC  field  of  a  STATISTICS 
REPORT  message  shall  define  the  count  of  16-bit  words  which  exist 
within  the  data  field  rather  than  the  count  of  24-bit  records. 

3. 2. 1.1. 3. 3. 9  SET  FILTER  Message 

The  data  field  of  a  SET  FILTER  message  shall  consist  of  a 
sequence  of  32-bit  records,  one  for  each  filter  word  being  set.  The 
first  word  shall  consist  of  the  address  of  the  filter  word  to  be  set, 
while  the  second  word  shall  be  the  value  to  which  the  filter  word  is  to 
be  set.  The  WC  field  of  a  SET  FILTER  message  shall  define  the  count  of 
16-bit  words  which  exist  within  the  data  field  rather  than  the  count 
of  32 -bit  records. 

3.2.1.1.3.3.10  REPORT  MESSAGE  FILTER 

The  data  field  of  a  REPORT  MESSAGE  FILTER  message  shall 
consist  of  a  sequence  of  16 -bit  records,  one  for  the  address  of  each 
filter  word  for  which  a  report  is  requested. 

3.2.1.1.3.3.11  REPORT  FILTER  Message 

The  data  field  of  a  REPORT  FILTER  message  shall  be  identical 
to  that  described  for  a  SET  FILTER  message.  Only  implemented  filter 
words  shall  be  reported. 

3.2.1.1.3.3.12  SET  REALTIME  CLOCK 

The  data  field  of  a  SET  REALTIME  CLOCK  message  shall  consist 
of  a  48-bit  record  containing  the  current  time  value  to  be  loaded 
into  the  realtime  clock,  The  WC  field  of  a  SET  REALTIME  CLOCK  message 
shall  define  the  count  of  16-bit  words  which  exist  within  the  record 
rather  than  the  record  count. 

3.2.1.1.3.3.13  REALTIME  CLOCK  REPORT 

The  data  field  ci  a  REALTIME  CLOCK  REPORT  message  shall  be 
identical  to  that  of  a  SET  I'.EAL’IIME  CLOCK  message.  The  data  field 
shall  represent  the  time  value  of  the  local  realtime  clock  at  the  time 
the  token  was  received. 
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3. 2. 1.1. 3. 4  Alternate  Control  Message 

The  alternate  control  message  capability  shall  be  provided  at 
the  discretion  of  the  system  designer  of  a  specific  HSI)B  application. 

It  shall  be  used  to  specify  terminal  operations  which  sxe  Judged  to  be 
necessary  for  proper  network  operation  in  that  application  but  which 
are  not  defined  by  the  HSDB  systems  specification.  It.  should  be  noted 
that  alternate,  control  functions  will  not  be  compatible  across  systems 
boundaries . 

3.2. 1.1.4  Source  Address 

The  SA  field  shall  consist  of  a  status  bit  followed  by  the  7- 
bit  address  of  the  terminal  initiating  the  message.  Bit  #1  of  the 
field  shall  be  the  most  significant  bit  of  the  address.  Bit  #0  shall 
be  set  to  logic  "0"  except  in  the  case  of  a  ring  master  terminal.  The 
ring  master  terminal  shall  set  bit  #0  to  logic  "I". 

3. 2. 1.1. 5  Destination  Address 

The  DA  shall  define  the  address  of  the  destination 
terminal(s)  for  which  the  message  is  intended.  The  first  two  bits  of 
the  FC  field  define  the  addressing  mode,  token  (00),  maintenance  (01), 
or  data  (10). 

3. 2. 1.1. 5.1  Token  Message 

Except  for  CLAIM  TOKEN  messages,  the  DA  field  for  a  token 
message  shall  consist  of  a  "0"  in  bit  #0  followed  by  the  7-bit 
address  of  the  terminal  for  which  the  token  message  is  intended.  Bit 
#1  shall  be  the  most  significant  bit  of  the  address. 

For  CLAIM  TOKEN  messages,  the  DA  shall  consist  of  the 
complement  of  the  SA  field. 

3. 2. 1.1. 5. 2  Maintenance  Message 

The  DA  field  for  a  maintenance  message  shall  normally  consist 
of  a  "0"  in  Bit  #0  followed  by  the  7-bit  address  of  the  terminal  for 
which  the  maintenance  message  is  Intended.  Bit  #1  shall  be  the  most 
significant  bit  of  the  address.  Broadcast  maintenance  messages  shal  1 
be  indicated  by  DA  -  "1"  in  all  bits. 

3. 2. 1.1. 5. 3  Data  Messuge 

The  DA  field  tor  a  data  message  shall  define  the  destination 
for  the  message.  Bit  of  the  DA  shall  define  the  addressing  mode, 

either  singlecast  (0)  or  content/broadcast  (1)  address,  followed  by  15 
bits  as  described  below. 

3. 2. 1.1. 5. 3.1  Singlecast  Address 

The  DA  field  for  singlecast  mode  shall  consist  of  bit  #0  set  to 
0  followed  by  a  7-bit  destination  field  cont.al.ning  the  address  of  the 
terminal  for  which  the  data  message  is  intended,  followed  by  an  8-bit 
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subaddces6  field.  The  subaddress  shall  be  all  zero  unless  a  specific 
subaddress  is  explicitly  requested  by  the  user  at  the  time  the  TMU  was 
initiated. 

3. 2. 1.1. 5. 3. 2  Content  Address 

The  DA  field  for  content  address  mode  shall  consist  of  bit  #0 
set  to  1,  followed  by  a  15-blt  content  descriptor.  Each  terminal  shall 
maintain  a  content  descriptor  filter  which  shall  determine  whether  or 
not  it  wishes  to  accept  a  particular  content  described  message. 

Address  FFFF  (hexadecimal)  shall  be  the  broadcast  address, 

3. 2. 1.1. 5. 3. 3  Broadcast  Address 

Destination  Address  FFFF  (hexadecimal)  shall  be  the 
broadcast  mode  address. 

3. 2. 1.1. 6  Word  Count 

The  word  count  field  shall  describe  the  number  of  16-bit  data 
words  which  are  included  in  the  data  field.  Word  count  shall  equal  the 
value  N-l  where  N  is  the  total  number  of  data  words  (from  1  to  4096 
inclusive)  included  in  all  records  of  the  message. 

3. 2. 1.1. 7  Data 

The  data  field  shall  consist  of  one  or  more  records  each 
followed  by  FCS.  A  message  consisting  of  more  than  256  words  >hall  be 
decomposed  into  2  or  more  records  containing  from  1  to  256  (inclusive) 
words  of  data.  There  shall  be  no  restrictions  on  the  format  of  the 
data.  The  terminal  shall  in  no  way  modify  the  contents  of  the  data  as 
part  cf  the  transmission/reception  process  except  to  intersperse  FCS 
as  described  above. 

37.1,1.8  Frame  Check  Sequence 

The  FCS  field  shall  consist  of  a  16-bit  Cyclic  Redundancy 
Check  (CRC)  pattern  covering  the  FC  +  5A  +  DA  +  WC  •+  Data  fields  of  the 
message.  CRC  shall  be  calculated  based  on  the  following  generator 
polynomial : 

G(X)  -  X16  X12  +  X5  +  1  (CCITT-CRC-16) 

If  the  data  message  from  the  user  contains  more  than  256 
words,  the  message  shall  be  split  into  a  sequence  of  256  word  (or 
remainder)  records  and  an  FCS  generated  for  and  appended  to  each 
record. 

3. 2, 1.1, 9  End  Delimiter 

The  ED  field  shall  consist  of  a  4  bit  time  sequence  of  valid 
and  invalid  symbols  which  is  the  complement  of  the  SD  field. 
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3.2.1.1.10  Maximum  Transmission  Time 

The  terminal  shall  contain  provisions  to  automatically 
terminate  attempted  transmissions  of  greater  than  the  equivalent  of  a 
4096  word  data  message  plus  a  token  message. 

3.2.1.1.11  Intermessage  Gap 

The  idle  period  between  adjacent  packets  on  the  bus  shall  be 
greater  than  100  ns  and  less  than  1250  ns. 

3.2.1.1.11.1  Terminal  Response  Time 

The  terminal  shall  begin  transmission  of  preamble  between  100 
and  200ns  from  detection  of  a  valid  message  if  the  message  is  addressed 
to  the  terminal  and  contains  the  token. 


3.2.1.1.11.2  Receiver  Recovery 

A  receiver  shall  be  capable  of  synchronizing  to  and 
recovering  adjacent  messages  from  the  bus  under  minimum  intermessage 
gap  times  and  maximum  message  dynamic  range  conditions.  A  receiver 
shall  be  capable  of  recovering  concatenated  messages  from  a  single 
source  separated  by  only  ED  +  SD. 

3.2.1.1.12  Redundancy 

Two  types  of  network  designs  shall  be  supported  by  the  HSDB, 
single  or  dual  redundant.  Networks  designed  to  operate  in  dual 
redundant  mode  shall  be  implemented  using  totally  independent  circuitry 
for  the  PHY  layer  and  MED  layers.  Terminal  MAC  layer  circuitry  may  be 
shared  if  reliability  requirements  can  be  met.  In  either  case,  a 
single  token  (and  copy)  shall  be  supported  by  the  network  on  both 
buses.  The  standby  bus  shall  not  be  used  as  a  separate  network. 

Dual  redundant  terminals  shall  be  capable  of  being  hard  strapped  or 
soft  programmed  to  operate  using  the  "A"  bus  only. 

n  i  n  urrv  t  _ _ 

J  ,  £  .  X  .  i..  L’LUU  Wijrc*.  a  C4  luj. uiauuc 

The  functions  of  the  MED  layer  is  to  provide  a  data 
transport  highway  between  terminals.  The  MED  layer,  in  either 
coaxial  or  FO  implementation,  shall  meet  the  following  requirements. 

a.  Maximum  number  of  terminals  -  64 

b.  Minimum  number  of  terminals  -  2 

c.  Maximum  terminal  separation  -  300  ft 

d.  Minimum  terminal  separation  -  1  ft 

e.  Radiated  energy  -  no  requirement. 

f.  Susceptibility  -  no  requirement 

3. 2. 1.2.1  Coaxial  Media  Unique  Characteristics 

The  MED  layer,  when  implemented  using  coaxial  media,  shall 
meet  the  following  requirements. 
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a 

b 

c 

<1 

e 

f 

g 
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k 

1 

m 

n 

P 
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Stub  length  •  max 
Stub  length  -  min 
Stub  attenuation  -  max 
Stub  characteristic  impedance  - 
Mainbus  Impedance 
Ma inbus  attenuation  -  max 
Coupler  loss  -  mainbus  in/out  - 
Coupler  loss  -  mainbus  to  Rx 
Coupler  loss  -  Tx  to  mainbus 
Coupler  Tx  port  impedance 
Coupler  Rx  port  impedance 
Connector  loss (per  mated  pair)- 
Propagation  delay  -  mainbus 
End  to  end  loss  -  max 
Coupler  mainbus  return  loss 
Differential  "AVB"  skew 


20  ft 
3  ft 

2 . 0  db  max  at  50  MHz 
50  ohms  ±2.0  ohms 
50  ohms  ±1.25  ohms 
13  db  total  at  50  MHz 
0 . 100  db  max 

25.75  db  ±0.5  db 

10.75  db  ±0.5  db 
50  ohms  ±5  ohms 
50  ohms  ±5  ohms 
0.011  db 

LT  500  ns 
54  db 

NLT  32  db  at  50  MHz 
NMT  400  ns 


A  simplified  system  signal  budget  diagram  is  shown  in  figure  2a. 

Note  that  the  end  to  end  loss  specification  is  consistent  with  a  64 
terminal  network  of  300  ft  overall  length  constructed  using  mainbus 
cable  exhibiting  a  loss  of  1.8  db/100  ft  at  50  MHZ.  Networks  of  longer 
length  shall  be  possible  given  fewer  terminals  or  lower  loss  mainbus 
cable,  within  the  mainbus  loss  specification.  Networks  of  more  than  64 
terminals  shall  be  possible  given  shorter  mainbus  and  stub  lengths 
and/or  lower  loss  cable,  within  the  system  loss  specification. 

3. 2, 1,2. 2  FO  Media  Unique  Characteristics 

The  MED  layer,  when  implemented  using  FO  media,  shall  meet 
the  following  requirements , 


a.  Stub  attenuation  -  max 

b.  Coupler  attenuation  -  max 

c.  Stub  cable  propagation 

d.  Stub  cable  bandwidth 

e.  Stub  diameter  (con  /cladding) 

f.  Stub  numerical  aperture 

g.  Stub  propagation  constant 

h.  Differential  /"i,"  skew 


4.5  db/km  @  850  nm 

21.5  db  any  input  to  any 
output 

Graded  index 
GT  30  MHz/km 
100/140  microns 
0.29  ±0.015 
GT  0.63 
NMT  400  ns 


A  simplified  power  budget  diagram  is  shown  in  figure  2b.  The  overall 
loss  specification  is  consistent  with  a  64  port  star  coupler  centered 
in  a  network  topology  of  300  ft  overall  length  with  a  single  connector 
per  stub.  Networks  of  longer  overall  length  are  possible  if  a  coupler 
with  fewer  than  64  ports  is  used,  within  the  constraints  of  the  overall 
system  loss  budget. 


3. 2. 1.3  PHY  Layer  Performance 


The  function  of  the  PHY  layer  is  to  translate  data  presented 
in  message  form  from  the  MAC  layer  into  a  modulated  signal  (packet) 
compatible  with  the  transport  characteristics  of  the  MED  layer  and  to 
demodulate  packets  from  the  MED  layer  back  into  message  form  for 
presentation  to  the  MAC  layer.  The  PHY  layer  shall  be  implemented  iri 
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the  form  of  a  Transmit/Receive  Unit  (TRU)  contained  within  each 
terminal.  Figure  6  Illustrates  the  functional  characteristics 
of  the  TRU.  Requirements  common  to  both  types  of  TRU  (coaxial  and 
F0)  are  stated  below. 


a. 

TX  Bit  rate 

-  50  Mbps  +0.0125  Mbps 

b. 

RX  acquisition  range 

-  50  Mbps  +0.025  Mbps 

c . 

Preamble  (clock  sync) 

-  8  bits 

d. 

Start  delimiter 

-  4  bit  times 

e . 

End  delimiter 

-  4  bit  times 

f. 

Transmitter  timeout 

-  1.3  ms  +  0.13  ms/-0.0  ms 

6- 

System  error  rate 

-  LT  5X10E-11  BER 

Over  operating  envelope 

for 

dual  redundant  terminals, 

a  single  transmit  message  from 

the  MAC  layer  results  In  two  packets  being  sent,  one  or.  the  "A"  port 
and  one  on  the  "B"  port.  Conversely,  two  packets,  one  from  RX-"A"  port 
and  another  from  the  RX-"B"  port  result  in  two  received  messages  being 
sent  to  the  MAC  layer . 


3. 2. 1.3.1  Coaxial  TRU 


The  coaxial  TRU  shall  provide  the  electrical  and  physical 
interface  of  each  terminal  with  the  MED  layer  of  a  coaxial 
implementation  of  the  HSDB,  Requirements  unique,  to  the  coaxial  TRU  are 
stated  below. 


a.  Modulation 

b.  Tx  output  level 

c.  Tx  polarity 

d.  Bit  symmetry 

a.  Tx  switch  output  level  •• 

Tx  state 

f.  Tx  switch  output  level  - 
Rx  state 

g.  Tx  switch  risetime/falltime 

h.  Rx  input  sensitivity 

J .  Rx  dynamic  range 

k.  Input  impedance 

l.  Clock  sync 

m.  Rx  polarity 


-  Manchester  II 

-  15.0  +1.0Vp-p  into 
50ohms 

*  negative  transition  at 
mid  bit  -  logic  "X" 

-  50%  +10% 

-  11  +4  into  50  ohms 

-  -2.5+0.25  Vdc  into 
50  ohms 

-  LT  100  ns 

-  25  mV  p-p  for  stated 

cirot  rate 

•  NLT  27db 

-  50  ohms  +5  ohms 

-  To  within  3  ns 
within  6  bits 

-  Negative  transition 

at  mid  bit  -  logic  "l" 


3.2.1. 3.2  FO  TRU 


The  FO  TRU  shall  provide  the  electrical  and  physical 
interface  of  each  terminal  with  the  MED  layer  of  a  FO  implementation 
of  the  HSDB.  Requirements  unique  to  the  F0  TRU  are  stated  below. 


a.  Modulation  -  Manchester  equivalent 

b,  Tx  output  level  -  200uw-Pk  to  4Q0uw-Pk 
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c . 

Tx  wavelength 

-  850  nm  +30  run 

d. 

Tx  spectrum 

median 

-  G'f  75%  of  the  power 

e . 

Tx  polarity 

shall  be  within  30nm  of 
median  wavelength 
-  Power  in  first  1/2 

f . 

Tx  bit  symmetry 

bit  period  —  logic  "1" 

-  50%  +10% 

g- 

Tx  rise/fall  time 

-  LT  4ns 

h. 

Rx  sensitivity 

-  GT  luw-Pk  for  stated 

J. 

Rx  dynamic  range 

error  rate 
-  21db  or  greater 

k. 

Clock  sync 

-  To  within  3ns 

1. 

Rx  polarity 

within  6  bit  periods 
-  Power  in  first  1/2 

m. 

Rx  Rise/full  time 

bit  period  ~  logic  "1" 

-  LT  5ns  for  stated  error 

MAC 

Layer  Performance 

rate 

The  function  of  the  MAC  layer  is  to  manage  participation  of 
the  terminal  in  network  transactions  including  data  transmission  and 
reception,  token  management,  and  network  maintenance  functions.  The 
MAC  layer  shall  perform  all  protocol  functions  of  the  terminal  in  a 
manner  so  as  to  appear  transparent  to  higher  layers  of  control 
within  the  terminal. 

A  token  passing  protocol  shall  be  implemented  by  the 
MAC.  The  token  address  of  each  terminal  shall  be  identical  to  the 
terminal  address  (TA)  hardwired  into  each  terminal .  Each  terminal 
shall  have  an  unique  TA. 

a.  A  token  shall  control  the  right  of  access  to  the  physical 
medium;  the  terminal  which  holds  the  token  shall  have 
singular  momentary  control  over  the  medium. 

b.  The  token  shall  be  passed  among  terminals  residing  on  the 
network  in  ascending  order  of  their  TAs,  thus  sharing 
network  bandwidth  in  a  planned  manner.  A  logical  ring 
control  structure  shall  thus  be  superimposed  on  the  linear 
physical  structure  of  the  network. 

c.  Nominal  operation  of  the  network  shall  consist  of  a  data 
transfer  phase  (optional)  and  a  token  transfer  phase  on  the 
part  of  each  terminal  during  each  network  rotation. 

d.  Token  maintenance  functions  shall  reside  in  each  and  every 
terminal  for  the  purposes  of  initializing  the  logical  ring, 
lost  token  recovery,  station  deletion,  new  station  addition, 
and  general  housekeeping. 

The  MAC  shall  perform  as  a  loosely  coupled  set  of  four 
logical  machines  as  shown  by  figure  7.  Data  and  control/status 
information  shall  be  communicated  into  and  out  of  the  MAC  in  the  form 
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TERM 


RX  TX 

MESSAGE  MESSAGE 


FIGURE  7 


MAC  LAYER  FUNCTIONAL  DESCRIPTION 


a  set  of  transaction  data  units.  TX  Units  and  Terminal  Management 
iits  shall  be  operated  upon  to  create  TX  messages  for  presentation  to 
,e  PHY  layer.  RX  messages  from  the  PHY  layer  shall  be  decoded  so  tha 
ilv  properly  received  RX  Units  are  presented  to  the  User.  Upon 
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from  the  MAC  at  a  rate  consistent  with  the  operating  bus  rate  of  the 
terminal . 

TABLE  XIII 
TXC  FUNCTIONS 

Function  Requirement 

Frame  control  8  bits 

Source  address  7  bits 

Destination  address  16  bits 

When  the  terminal  is  operating  In  maintenance  re -transmit  mode,  TXC 
shall  consist  of  the  turnaround  message  to  be  placed  on  the  bus. 

3. 2. 1.4. 1.5  Terminal  Control  Unit  <TCU) 

The  TCU  shall  consist  of  a  set  of  data  bits  which  define 
the  operating  mode  of  the  terminal,  to  request  transmission  of  a  data 
block,  or  to  request  network/termlnal  maintenance  information.  The 
functions  described  in  Table  XII  shall  be  accommodated, 

3. 2. 1.4. 1.6  TX  Message  (TXM) 

The  TXM  shall  consist  of  a  serial  data  stream  comprising  the 
message  to  be  sent  by  the  terminal,  in  the  format  "FC  +  DA  +  SA  +  WC  + 
Data  +  FCS."  The  data  stream  shall  be  clocked  from  the  MAC  layer  at 
the  rate  and  time  required  to  support  the  operating  bus  rate  of  the 
terminal . 

3. 2. 1.4. 1.7  RX  Message  (RXM) 

The  RXM  shall  consist  of  a  serial  data  stream  comprising  the 
message  being  recovered  by  the  terminal.  It  shall  be  in  the  same 
format  as  present  on  the  network  without  the  ED  and  SD  fields  but 
Including  the  "FC  +  DA  +  SA  +  Data  +  FCS"  fields. 

3. 2. 1.4. 1.8  RX  Data  Unit  (RXD) 

The  RXD  shall  consist  of  the  contents  of  the  "Data"  field  of 
the  message  just  received  from  the  network.  RXD  shall  be  initiated 
only  after  FCS  has  been  validated  against  the  frame  contents  and  the 
destination  address  is  found  to  correspond  with  a  va3 id  destination 
address . 

3. 2. 1.4. 1.9  RX  Control  Unit  (RXC) 

The  RXC  shall  consist  of  a  bi-directional  data  path  used  to 
coordinate  the  reception  of  messages.  Valid  destination  address(es) 
shall  be  passed  from  the  access  and  protocol  machine  to  the  receive 
machine  (refer  to  figure  5).  The  "FC  -t  SA"  fields  from  each  received 
message  shall  be  passed  from  the  receive  machine  to  the  access  and 
protocol  machine. 
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3.2.1.4.1.10  RX  Unit:  (RXU) 

The  RXU  shall  consist  of  a  data  block  comprising  the  "Data" 
field  of  a  alngle  message.  It  shall  be  passed  from  the  MAC  layer  to 
the  USER  at  the  convenience  of  the  user.  The  data  shall  be  organized 
as  a  block  of  from  1  to  4096  16  bit  binary  words. 

3.2.1.4.1.11  Configuration  Reporting  Unit  (CRU) 

The  CRU  shall  be  used  to  report  information  relative  to 
network  and  terminal  operations.  Unique  identifiers  shall  be  provided 
to  accommodate  the  functions  described  in  Table  XIV  plus  a  minimum  of 
50%  spares . 


I 


Function 


TABLE  XIV 
CRU  FUNCTIONS 


Terminal  configuration 
Terminal  status 
Network  configuration 
Statistics 

3.2.1.4.1.12  Terminal  Status  Unit  (TSU) 


Requirements 

16  bits 
16  bits 

Per  3.2.1.4.2.12 
Per  Table  XI 


The  TSU  shall  be  initiated  upon  receipt  of  a  valid  message 
from  the  bus  or  upon  request  of  the  user.  In  the  former  case,  it 
shall  inform  the  user  of  the  message  location,  size,  source,  class  of 
service,  and  priority.  In  the  latter  case,  it  shall  respond  to  the 
specific  request  of  the  user. 

3. 2. 1.4. 2  Functional  Requirements 


The  MAC  layer  shall  perform  as  a  loosely  coupled  set  of  four 
logical  machines  as  described  in  figure  7.  The  heart  of  the  MAC 
is  the  access  and  protocol  machine.  Its  function  is  the  establishment 
and  maintenance  of  the  network  and  coordination  of  other  functions 
within  the  MAC. 


3. 2. 1.4. 2.1  Steady  State  Network  Operation 

Steady  6tate  network  operation  shall  require  the  sending  oi 
the  token  to  a  specific  successor  when  each  terminal  is  finished 
transmitting  scheduled  traffic,  if  any.  Hie  sequence  of  messages 
involved  in  information  transfer  is  illustrated  in  Figure  8.  After 
sending  the  token,  the  terminal  shall  listen  for  evidence  that  its 
successor  has  passed  the  token.  If  the  token  sender  does  not  hear 
evidence  that  the  token  pass  was  successful,  it  shall  begin  a  series  of 
recovery  procedures  that  grow  increasingly  more  drastic  as  described  in 
3.2. 1.5.2.  If  all  attempts  prove  unsuccessful,  the  terminal  shall 
become  silent  and  wait  for  another  terminal  to  initiate  recovery 
procedures , 

3. 2. 1.4. 2. 2  Deleted 


token  l— token  .  ^  inessaqe  token 
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3, 2. 1.4. 2. 3  Realtime  Topology  Adaptation 

On  a  periodic  basis,  and  when  the  level  of  network  traffic  is 
sufficiently  low,  new  terminals  shall  be  allowed  access  to  the  network. 
The  sequence  of  transactions  is  described  in  Table  XV.  The  process 
shall  be  initiated  by  the  terminal  in  possession  of  the  token.  It 
shall  take  the  form  of  a  poll  to  one  potential  TA  between  its  own  TA 
and  the  TA  of  its  successor.  If  the  poll  is  successful,  the  logical 
ring  shall  be  broken  in  the  proper  TA  sequence  and  the  requesting 
terminal  shall  be  Inserted. 


TABLE  XV 

TOPOLOGY  ADAPTATION  TRANSACTION  SEQUENCE 


Soliciting  New  Previous 

Terminal  Terminal  Successor 


Solicit  Entry . . - . >* 

*<-- . Request  Entry 

Set  Successor . >* 

Set  Predecessor  . . . .  —  - — >* 

Pass  Token . >* 


3. 2. 1.4. 2. 4  Initialization  Process 

Initialization  of  the  network  shall  be  a  special  case  of 
adding  new  terminals  to  an  existing  network.  Each  potential 
initializer  shall  send  a  frame  having  a  length  proportional  to  its 
address.  The  terminal  shall  then  listen  to  the  bus.  If  all  other 
potential  Initializers  had  finished  transmitting  prior  to  that:  time, 
the  terminal  will  hear  a  quiet  bus  and  assume  that  it:  holds  the  only 
token  in  the  network,  It  will  then  proceed  to  form  the  network  by  a 
polling  technique. 

3. 2. 1.4. 2. 5  Priority 

A  4- level  priority  mechanism  shall  be  provided  for  use  at  the 
discretion  of  the  network  designer.  The  mechanism  shall  reserve  a  set 
amount  of  network  bandwidth  for  messages  at  each  nrioritv  level.  This 
shall  be  accomplished  by  using  a  set  of  three  token  rotation  timers  in 
each  terminal.  The  terminal  shall  send  only  messages  of  a  priori  t.y 
higher  than  Indicated  by  the  timers,  based  on  the  time  interval  since 
it  last  held  the  token. 

3. 2. 1.4. 2. 6  Maintenance  Functions 

Maintenance  functions  shall  be  provided  to  allow  the  quality 
of  service  being  experienced  by  any  terminal  to  be  reviewed  by  its  user 
or  by  any  other  user  in  the  network.  A  multilevel  maintenance 
strategy  shall  be  provided  in  each  terminal  as  described  below: 

a.  Bui 1 t- In-Test  (BIT)  shall  constantly  monitor 
critical  terminal  functions. 
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b.  The  terminal  receiver  shall  monitor  all  terminal 
transmissions . 

c.  A  local  loopback  mode  shall  be  provided  wherein  the 
user  shall  be  able  to  send  a  test  message  between 
transmitter  and  receiver  without  the  message 
appearing  on  the  network. 

d.  A  network  loopback  mode  shall  be  provided  wherein 
any  terminal  shall  be  able  to  originate  a  test 
message  to  Itself  from  another  terminal  on  the 
network.  Interaction  of  the  users  of  either 
terminal  shall  not  be  required. 

Performance  statistics  shall  be  computed  within  each  terminal 
describing  the  message  delays  for  each  priority  level,  the  number  of 
erroneous  messages  received,  average  and  peak  values  of  the  token  cycle 
times  and  other  parameters  of  significance  to  the  system  designer. 
Registers  associated  with  statistics  shall  be  reset  each  time  the 
statistic  is  reported.  Registers  which  reach  overflow  state  before 
being  reported  shall  retain  the  maximum  count  until  reported. 

3. 2, 1.4,2, 7  Realtime  Clock 


A  48-bit  realtime  clock  (RTC)  shall  be  established  within 
each  terminal  at  Initialization.  The  clock  may  be  set  by  the  user,  set 
from  the  network,  read  by  the  user,  or  read  from  the  network.  The  RTC 


r.W  in  a  i  u  acti 


ix  pc  i.  i.ui 


without  drift  correction.  Clocks  within  different  terminals  on  the 
network  shall  be  synchronized  to  within  10  microseconds  using  drift 
rate  correction  and  1  second  update  rate.  Clocks  within  different 
terminals  on  the  network  shall  be  synchronized  to  within  3  microseconds 
using  drift  rate  correction,  differential  delay  correction  and  1  second 
update  rate.  Provisions  shall  be  included  to  allow  the  embedded  clock  of 
any  terminal  to  be  defined  as  the  master  clock.  It  shall  also  be 
possible  to  synchronize  the  master  clock  to  some  high  accuracy  time 
reference  located  external  to  the  terminal. 


3. 2. 1.4. 2. 8  Acknowledgment 

Automatic  acknowledgment  of  messages  is  not  a  function  of  the 
HSDIi.  Whenever  acknowledgment  is  required  to  meet  system  performance 
needs,  the  function  shall  be  provided  by  the  user. 

3. 2. 1.4. 2. 9  Retry 

Automatic  retry  of  token  pass  messages  shall  be  in  accordance 
with  the  applicable  paragraphs  of  this  specification.  Automatic  retry 
of  data  and  maintenance  messages  is  not  a  function  of  the  HSDB. 
Whenever  required  to  meet  system  performance  needs,  the  function  shall 
be  provided  by  the  user. 
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3.2.1.4.2.10  Redundant  Bus  Operation 

A  dual  path  redundant  network  design  shall  be  the  preferred 
implementation  approach.  A  single  path  network  shall  be  non-preferred 
but  shall  be  accommodated  within  the  design  of  dual  bus  terminals.  A 
single  bus  terminal  shall  be  a  non-preferred  case  but  shall  be 
accommodated  within  a  dual  path  redundant  network. 

Redundant  terminals  shall  transmit  and  receive  on  both  the 
"A"  bus  and  the  "B"  bus  at  all  times  thus  effectively  providing 
parallel  equivalent  transmission  paths  throughout  the  network.  The 
message  first  arriving  at  the  terminal  shall  be  recovered  unless  it 
contains  one  or  more  transmission  errors.  In  that  case,  the  later 
arriving  message  shall  be  recovered. 

3.2.1.4.2.11  Message  Filter 

Terminals  shall  accept  content  addressed  messages.  A  content 
descriptor  messAge  filter  shall  be  used  for  this  purpose.  Hie  content 
descriptor  filter  shall  consist  of  a  series  of  (2]  -1)  bits  which  are 
either  set  or  clear,  depending  on  whether  (1)  or  not  (0)  the  terminal 
is  to  receive  the  data  containedi  within  the.  message.  The  filter  is 
organi?.ed  as  an  array  of  up  to  2^  words  of  16  bits  each.  Content 
address  0  corresponds  to  word  #0,  bit  #0.  Content  address  1 
corresponds  to  word  #0,  bit  #1.  In  general,  content  descriptor  N  shall 
correspond  to  the  word  described  by  the  integer  portion  of  (N/16)  and 
the  bit  described  by  (N  MOD  16). 

3.2.1.4.2.12  Topology  Memory 

Each  terminal  shall  include  provisions  for  a  topology  memory 
function  for  use  in  error  detection  and  recovery.  The  topology  memory 
shall  accommodate  126  terminal  records.  All  but  the  "this  terminal" 
record  shall  contain  fields  as  described  below, 


a . 

b. 

c . 
d 

e. 


f . 

&■ 


Terminal  Address  (TA) : 
Current  Predecessor 
Address  (CP) : 

Current  Successor 
Address  (CS): 

Status;  Range  —  on-line 
Initial  Value  - 
Operational  Ports:  XXXI  - 

XXIX  - 


0  through  127 
0  through  253 
255  (error) 

-  0  through  255 

-  255  (error) 
(01),  absent  (00) 


Ringmaster : 
Timekeeper ; 


Range  - 

Range  ~ 

Initial  Value  - 
Range  — 

Initial  Value  — 

(11),  off-line 
ABSENT 

Receive  on  "A" 

Receive  on  "B" 

X1XX  -  Transmit  on  "A" 

1XXX  -  Transmit  on  "B" 

Initial  Value  —  0000 
Range  -  NOT  RINGMASTER  (0) , 

RINGMASTER  (1).  Initial  Value  -  0 
Range  -  NOT  TIMEKEEPER  (0) , 

TIMEKEEPER  (1).  Initial  Value  -  0 


Except  as  noted  below,  the  topology  memory  shall  be  set  to 
its  initial  state  each  time  power  is  applied.  The  status  field  shall 
be  settable  either  by  the  user  or  from  the  network  via  a  SETT0P0L0GY 
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message.  The  predecessor  address  and  successor  address  fields  shall  be 
settable  from  the  network  via  a  SET_PREDECESSOR  and  SET_SUCCESSOR 
message,  respectively,  or  by  a  SET_TOPOLOGY  message. 

The  "this  terminal"  entry  in  the  topology  memory  shall  be 
identical  to  those  listed  above  and  shall  be  controlled  in  the  same 
manner  except; 


a.  The  terminal  address  shall  be  hardwire  strapped  in  the 
terminal . 


b.  Status  shall  be  settable  from  either  the  user  function 
or  from  the  terminal  itself.  The  initialization  value 
shall  be  "OFF-LINE."  The  value  "ABSENT"  is  undefined. 

c.  Enable  bus  shall  be  set  based  on  the  type  of  terminal 
(single  bus/dual  bus)  and  the  results  of  BIT. 

3.2.1.4.2.13  Network  Activity  Monitor 


Each  terminal  shall  include  a  network  activity  monitor  which 
shall  trigger  whenever  a  signal  is  being  received  from  the  network. 

The  monitor  shall  derive  its  determination  of  network  activity  from 
measurement  of  RMS  power  at  the  receive  stub  port  of  the  terminal  as 
defined  below. 


a , 

Sensitivity  - 

wire  bus  terminal 

5uw 

b. 

Sensitivity  - 

F0  terminal 

0 . 5’jv; 

c . 

Dynamic  range 

-  wire  bus  terminal 

30db 

d. 

Dynamic  range 

-  F0  terminal 

24db 

e . 

Response  Time 

60ns 

f. 

Recovery  time 

(from  maximum  signal) 

140ns 

Dual  redundant  terminals  shall  include  an  independent  monitor  function 
for  each  RX  port. 

3, 2, 1.4. 3  Timers 


Each  terminal  shall  include  10  timer  functions  used  to 

-  *  - - -  «  f 
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relationship  to  other  terminal  functions  is  illustrated  by  figure  9. 
The  clock  of  each  timer  except  the  Retry  Limit  Timer  shall  be  derived 
from  the  terminal  bit  clock  (nominal  50  MHz).  Each  timer  shall  be 
provided  with  a  default  initialization  value  as  defined  below.  The 
default  value  may  be  overridden  by  a  value  received  from  that 
terminal's  user  or  by  a  value  received  from  remote  user  via  of  a  SET 
PARAMETER  message. 


3. 2. 1.4. 3.1  Token  Hold  Timer 


A  token  hold  timer  (THT)  is  provided  to  limit  the  period  oi 
time  over  which  a  terminal  may  schedule  traffic.  The  THT  shall  be 
reset  to  its  initialization  value  whenever  the  terminal  receives  a 
token.  It  shall  count  toward  zero  at  a  rate  of  0.32uS  (bit  clock*16) 
so  long  as  the  terminal  holds  the  token.  The  default  initialization 
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BIT  CLOCK 


TOKEN  RECEIVED 

TOKEN  SENT 
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BIT  CLOCK 
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BIT  CLOCK 
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value  shall  be  265  word  times  (84.8us).  Programmable  initialization 
values  from  5  word  times  (1.6us)  through  4119  word  times  (1318us)  shall 
be  accepted. 

3. 2. 1.4. 3. 2  Token  Rotation  Timers 

Three  14-bit  token  rotation  timers  (TRT)  are  provided  to 
control  the  terminal's  access  to  the  network  at  each  priority  level. 

Each  TRT  shall  be  set  to  its  initialization  value  each  time  the  token 
is  received.  It  shall  begin  to  count  toward  zero  immediately 
thereafter . 

a.  TRT-P1  shall  be  used  to  govern  transmission  of  PI 
priority  messages  (high  priority).  The  clock  rate  for 
TRT-P1  shall  be  5.12us  (bit  clock*256).  The  default 
initialization  value  shall  be  1.31072ms  (rate  clock 
*256).  The  initialization  value  shall  be  programmable 
over  the  range  81.92.us  (rate  clock  *  16)  through 
83.881ms  (rate  clock  *  2*  j. 

b.  TR1-P2  shall  be  used  to  govern  transmission  of  P2 

priority  messages.  The  clock  rate  for  TRT-P2  shall  be 
twice  that  of  TRT-P1.  The  default  initialization  value 
shall  be  655.36us  (rate  clock  *  256).  The  initialization 
value  shall  be  programmable  over  the  range  4Q.96us  (rate 
clock  *  16)  through  41.940ms  (rate  clock  *  2  -  l). 

c.  TRT-F3  shall  ba  used  to  govern  transmission  of  P3 
priority  messages  (lowest  priority).  The  clock  rate  for 
TRT-P3  shall  be  twice  that  of  TR1-P2.  The  default 
initialization  value  shall  be  327.68us  (rate  clock  * 

256).  The  initialization  value  shall  be  programmable 
over  the  range  20.48us  (rate  clock  *  16)  through 
20.970ms  (rate  clock  *  2-1). 

3. 2. 1.4. 3. 3  Ring  Maintenance  Timer 


Each  terminal  shall  include  a  14-bit  ring  maintenance  timer 
(RMT)  function  which  is  used  to  defer  realtime  topology  adaptation 
wm is  tne  ous  is  neavj. j.y  xuuu eu,  The  RMT  shall  be  set  to  its 
initialization  value  each  time  the  token  is  received.  It  shall  count 
toward  zero  until  the  next  reset  occurs.  The  clock  rate  shall  be  twice 
that  of  TRT-P3.  The  default  initialization  value  shall  be  163.84us 
(rate  clock  *  256).  The  initialization  value  shall  be  programmable 
over  the  range  10.24us  (rate  clock  *  16)  through  10.486ms  (rate  clock  * 
121  -1) . 


3. 2. 1.4. 3. 4  Solicit  Entry  Timer 


Each  terminal  shall  include  a  16-bit  solicit  entry  timer 
(SET)  function  which  is  used  to  Indicate  to  the  terminal  that  a  new 
successor  shall  be  sought,  SET  shall  be  set  to  its  Initialization 
value  each  time  a  successor  is  solicited,  whether  said  solicitation  is 
successful  or  not.  The  timer  shall  be  decremented  at  a  rate  of  20.48us> 
(bit  clock  *  1024)  until  the  next  reset  occurs  or  until  reaching  zero 
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count.  The  default  initialization  count  shall  be  10,5ms  (rate  clock  * 
512).  The  initialization  value  shall  be  programmable  over  the  range 
20.4tos  (rate  clock  *  2°)  through  1.34  sec  (rate  clock  *  2^-1). 

3. 2. 1.4. 3. 5  Network  Inactivity  Timer 

Each  terminal  shall  include  an  8 -bit  network  inactivity  timer 
(NIT)  which  is  used  to  indicate  that  the  network  has  bean  idle  for  an 
unexpected  period.  The  NIT  shall  be  set  to  its  initialization  value 
each  time  the  network  activity  monitor  indicates  that  the  network  is 
idle.  It  shall  count  toward  zero  at  a  rate  of  80ns  (bit  clock  *  4) 
until  the  counter  reaches  zero  (network  inactivity  error)  or  until  the 
monitor  recognizes  activity  on  the  network.  The  default  initialization 
count  shall  be  5.12us  (rate  clock  *  64).  The  initialization  value 
shall  be  programmable  over  the  range  320ns  (rate  clock  *  4)  through 
20.40us  (rate  clock  *  255).  Dual  redundant  terminals  shall  Implement  a 
single  NIT  function  for  both  Rx  ports.  Activity  on  a  single  port  shall 
be  sufficient  to  reset  the  NIT. 

3. 2. 1.4. 3. 6  Response  Window  Timer 

Each  terminal  shall  include  a  7 -bit  response  window  timer 
(RWT)  which  is  used  to  determine  when  a  token  has  been  lost  or  when  a 
SOLICIT  ENTRY  message  has  had  no  response.  The  RWT  shall  be  set  to  its 
initialization  value  each  time  the  terminal  terminates  (ED)  a  packet. 

It  shall  count  toward  zero  at  a  rate  of  80ns  (bit  clock/4)  until  the 
counter  reaches  zero  (no-response  error)  or  until  the  terminal 
recognizes  a  message  with  !>A  —  the  destination  address  of  its  previous 
message  (successful  response).  The  default  Initial ization  count  shall 
be  2.56us  (rate  clock  *  32).  The  initialization  value  shall  be 
programmable  over  the  range  320ns  (rate  clock  *  4)  through  10.16us 
(rate  clock  *  127).  Dual  redundant  terminals  shall  implement  a  single 
RWT  function.  A  valid  response  received  from  either  RX  port  shall 
terminate  the  countdown.  The  terminal  design  shall  ensure  that  RWT  is 
always  set  shorter  than  NIT. 

3. 2. 1.4. 3. 7  Retry  Limit  Timer 

Each  terminal  shall  include  a  3-bit  retry  limit  timer  (RLT) 
which  is  used  to  determine  the  number  of  retries  on  a  token  pass  before 
instituting  the  token  recovery  process.  The  RLT  shall  be  set  to  its 
Initialization  value  each  time  the  token  is  received.  It  shall  count 
toward  zero  at  a  rate  of  1  count  per  token  pass  attempt  until  the 
counter  reaches  zero  (token  pass  failure)  or  until  the  transaction  is 
successful.  The  default  initialization  value  shall  be  1.  The 
initialization  value  shall  be  programmable  over  the  range  1  through  7. 

3. 2. 1.4. 3. 8  Realtime  Clock  Synchronization  Timer 

Each  terminal  shall  include  a  10-bit  realtime  clock 
synchronization  timer  (RST)  which  is  use>  maintain  continuity  of  the 
realtime  clock  update  function.  Hie  RST  shall  be  set  to  its 
initialization  value  each  time  a  RTC  maintenance  message  is  received. 

It  shall,  count  toward  zero  at  a  rate  of  10ms  until  the  counter  reaches 
zero  or  until  reset.  The  initialization  value  shall  be  programmable 
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over  the  range  100ms  through  10  sec.  Two  default  initialization  values 
shall  be  provided,  TIMEKEEPER  (TK)  -  1.0  sec,  and  not  TIMEKEEPER  (TKF) 

—  2.0  sac, 

3. 2. 1.4. 4  State  Machine  Descriptions 

The  MAC  layer  shall  perform  as  a  loosely  coupled  set  of  four 
state  machines.  The  physical  and  electrical  implementation  of  a 
terminal  shall  be  at  the  discretion  of  the  terminal  designer  so  long  as 
the  functional  requirements  described  herein  are  met,  so  as  to  ensure 
the  compatibility  of  different  terminal  designs. 

3. 2. 1.4. 4.1  Access  and  Protocol  Machine  (APM)  Description 

Normal  operation  of  the  APM  function  shall  conform  to  the 
architecture  described  in  figure  10.  Operation  of  the  terminal  under 
error  conditions  shall  be  as  described  in  3. 2. 1.5. 

3. 2. 1.4. 4. 1.1  Off-Line  State 

The  terminal  shall  enter  off-line  (state  1)  immediately 
following  power  up  or  following  detection  of  certain  fault  conditions. 
This  state  shall  be  limited  to  self  test  functions  which  do  not 
transmit  on  the  network.  After  completing  self  test,  the  terminal 
shall  remain  in  state  1  until  all  initialization  parameters  have  been 
received  from  the  user  and  it  has  been  instructed  to  go  on-line.  That 
sequence  shall  cause  the  terminal  to  transition  to  the  IDLE  state. 

3. 2. 1.4. 4. 1.2  IDLE  State 

While  in  IDLE  (state  2),  the  terminal  shall  monitor  the 
network  for  activity.  Dependent  upon  network  traffic  intercepted,  the 
appropriate  next  state  shall  be  entered  as  follows:. 

a.  If  the  NIT  expires  with  no  activity  monitored  on  the 
network,  the  CLAIM__TOKEN  state  shall  be  entered. 

b.  If  the  terminal  is  on-line  and  a  token  message  addressed  to 
that  station  is  received,  the  transition  shall  be  to  USE 

WAW  PM  ..  _ _ _ _ 

J.  W  IN.  C-  LI 

c.  If  a  SOLXCIT_ENTRY  message  of  the  terminal's  address 
is  received  and  the  terminal  desires  entry  to  the 
network,  the  ENTER_NET  state  shall  be  entered. 

d.  If  a  built-in-test  fault  is  noted,  the  OFFJLINE  state 
shall  be  entered. 

3. 2. 1.4. 4. 1.3  USE_T0KEN  State 

TJSE_T0KEN  (state  3)  is  the  state  from  which  the  terminal 
shall  transmit  data  messages  on  the  network.  It  shall  enter  state  3 
from  state  2  or  state  5  whenever  it  receives  a  val  id  token  from  the 
network.  It  shall  enter  from  state  6  when  It  has  claimed  the  token 
from  an  initialization  process. 
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Exhaustive  class  of  service  shall  be  the  preferred  and 
default  mode  of  operation  for  HSDB  terminals,  The  process  is  illustrated 
in  figure  11. 

a.  The  transmit  queue  shall  be  tested.  If  empty,  the 
scheduled  traffic  shall  be  sent  and  the  terminal 
shall  transition  to  PASSTQKEN  state.  Note  that 
the  PASSJTOKEN  state  is  outside  the  jurisdiction  of 
the  THT. 

b.  Assuming  that  the  queue  is  not  empty,  examine  the 
top  (oldest)  message  in  the  queue.  If  it  will  fit 
within  the  remaining  schedule,  move  it  from  the 
queue  to  the  schedule. 

c.  Calculate  the  THT  remainder. 

d.  Increment  the  queue  to  the  next  oldest  message. 

e.  Repeat  steps  a  through  d  until  the  entire  queue  has 
been  examined  or  until  the  THT  has  been  exhausted. 

When  using  multiple  level  priority  class  of  service,  the  USE__T0KEN 
process  shall  progress  in  accordance  with  figure  11. 

a.  The  three  TRTs  shall  be  tested  and  the  appropriate  flag 
(FI,  F2,  F3)  either  set  (TRT  active)  or  cleared 

(TRT  timed  out) . 

b.  The  TRTs  shall  be  reset  to  their  initialization  value 
and  shall  begin  decrementing. 

c.  The  first  message  in  the  PO  queue  shall  be  placed  in 
the  schedule  and  the  length  of  the  message  shall  be 
deleted  from  the  THT  register. 

d.  The  next  message  in  the  PO  queue  shall  be  checked 
against  the  THT  remainder.  It.  shall  be  scheduled  as 
described  in  step  c  above  if  its  length  Is  less  than  the 
value  of  THT  remainder. 

e.  The  process  shall  continue  as  described  above  for  the 
remainder  of  the  PO  message  queue. 

f.  FI  shall  be  checked.  If  set,  messages  at  the  PI 
level  shall  be  scheduled  as  described  for  PO  in  steps  c 
through  e  above. 

g.  Similarly,  lower  priority  messages  (P2  and  P3)  shall  be 
scheduled  so  long  as  the  flags  and  THT  allow. 

h.  Scheduled  traffic  shall  be  sent  in  the  order  scheduled 
(highest  priority  first) . 

i.  The  terminal  shall  transition  to  the  PASS  TOKEN  state. 
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3. 2. 1.4. 4. 1.4  PASS_TOKEN  State 

PASS_TOKEN  (state  4)  is  the  state  from  which  control  of  the 
network  is  relinquished  to  a  successor  terminal.  It  shall  only  be 
entered  from  the  USE_TOKEN  state  and  shall  always  transition  to  the 
IDLE  state. 


The  PASS_TOKEN  process  shall  progress  in  accordance  with 

figure  12. 

a.  The  ring  maintenance  timer  (RMT)  shall  be  tested.  If  it 
has  timed  out,  the  token  shall  be  passed  without 
soliciting  for  a  new  successor. 

b.  The  Solicit  Entry  Timer  (SET)  shall  be  checked.  If 
inactive,  the  process  to  look  for  a  new  successor  shall  be 
initiated.  If  the  SET  is  still  active,  the  token  shall  be 
passed  without  soliciting  for  new  terminals. 

c.  The  network  topology  map  shall  be  checked  to  confirm 
that  one  or  more  potential  successors  exist.  If  the 
current  successor  (CS)  equals  the  terminal  address  +1,  then 
no  potential  successors  exist  and  the  token  shall  be  passed 
without  soliciting  for  new  terminals. 

d.  Assuming  the  three  tests  (above)  have  passed,  the 
terminal  shall  perform  the  SOLICIT  ENTRY  process  as 
described  in  3. 2. 1.4. 4. 1.7, 

e.  The  terminal  shall  pass  the  token  to  its  successor. 

3. 2. 1.4. 4. 1.5  ENTER  NET  State 


The  ENTER_NET  (state  5)  state  shall  be  Initiated  upon  command 
of  the  terminal  us'r  and  upon  receipt  of  a  SOLICIT_ENTRY  message  from 
the  network.  As  11 iustrated  by  figure  13,  the  terminal  shall  respond 
to  the  S 0L1 C I T__EN TRY  message  by  sending  a  REQUEST_ENTRY  + 
TERMINAL_STATUS_SUMMARY  maintenance  message.  Assuming  that  the 
soliciting  terminal  recognizes  the  REQUEST_ENTRY  message,  It  shall 
splice  the  new  Leiminal  into  the  logical  ring  using  SET  SUCCESSOR  and 
SET_PREDECESSOR  messages  and  then  pass  the  token  to  the  NEW  terminal 
which  will  transition  to  the  USE_TOKEN  state.  The  normal  sequence  of 
transactions  is  described  in  Table  XV. 


If  the  next  token  pass  message  on  the  network  is  not 
addressed  to  the  terminal  requesting  entry  then  that  terminal  shall 
assume  that  its  claim  was  not  recognized  and  will  transition  to  the 
IDLE  state. 


3. 2. 1.4, 4. 1.6  CLA1MJT0KEN  State 

The  CLA1M_T0KEN  state  (state  6)  shall  be  entered  from  the 
idle  state  when  the  Network  Inactivity  Timer  (NIT)  expires.  The 
terminal  shall  attempt  to  initialize  (or  reinitialize)  the  ring  using 
the  procedure  described  in  figure  14. 
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Each  terminal,  upon  recognizing  the  need  to  reinitialize  the 
network,  shall  send  £  sequence  of  concatenated  CLAIK_T0KEN  messages. 

The  number  of  messages  shall  be  proportional  to  the  terminal's  TA 
according  to  the  algorithm:  "Quantity  —  Ta+1  (1  to  128)".  Each  message 
shall  consist  of  the  sequence  SD  +  FC  +  DA  +  1>A  +  SA  +  FC  +  FC  +  FCS  + 
ED. 

When  the  CLAIM_TOKEN  sequence  is  complete,  the  terminal  chal  1 
wait  250  ns  to  allow  for  differential  propagation  time  and  shall  then 
monitor  the  network  for  activity.  If  the  bus  is  active,  the  terminal 
shall  assume  it  has  lost  the  CL/vIMTOKEN  process  and  shall  transition 
to  IDLE  state  in  order  to  allow  another  terminal  to  initiate 
COLD_START.  If  the  network  is  quiet,  it  shall  assume  that  it  has  won 
the  claim  process  and  shall  initiate  C0LD_START. 

A  terminal  listed  in  the  topology  memory  as  not  operational 
on  the  "A"  bus  shall  not  initiate  CLA1M._  TOKEN  state. 

3. 2. 1.4. 4. 1.7  S OLI C I T_EN TRY  Process 

The  S0L1CIT_ENTRY  process  shall  be  initiated  from  the  PASS 
TOKEN  state  as  described  above.  Figure  15  describes  the  process. 

Table  XV  describes  the  transaction  sequence  between  soliciting  terminal 
and  the  terminal  desiring  entry  to  the  network. 

a.  The  soliciting  terminal  shall  send  a  S  0  L  I.  C I  T_  E  NT  K  Y 
message  addressed  to  Potential  Successor  (PS). 

b.  The  soliciting  terminal  chall  wait  RViT  for  a  response 
from  the  network.  If  no  response  in  recognized  or  if 
the  response  is  not  a  REQUE$T_ENTRY  message  then  the 
terminal  assumes  that  the  request  has  had  no  response 
and  prepares  for  the  next  S0LICIT_ENTRY  process  (step 
e). 

c.  If  the  request  received  a  valid  response,  the.  terminal 
shall  break  the  logical  ring  and  splice  PS  into  it  by 
sending  a  SET_SUCCESS0R  message  to  PS  and  a 

SET  PREDECESSOR  massacre  to  CS . 

—  -  —  -  c;  -  ’  ~  ' 

d.  The  soliciting  terminal  shall  update  its  own  topology 
memory  to  include  the  new  token  rotation  sequence  and 
the  status  information  from  the  new  terminal  and  shall 
broadcast:  the  new  topology  to  the  network  via  a 
SET_T0PQLQGY  message. 

ft .  The  soliciting  terminal  shall  prepare  Itself  for  the 

next  SOLI CIT_ENTRY  process  by  incrementing  PS  (PS  -  PS  -t 
1)  and  checking  to  determine  if  PS  —  CS.  If  PS  -  CS 
then  reset  PS  to  PS  —  TA  -t  1  to  restart  the  cycle 
If  PS  /  CS  then  retain  PS. 

£.  The  soliciting  terminal  shall  reset:  its  SET  and 
transition  to  PASS_T0KEN  state. 
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3. 2. 1.4. 4. 1.8  LEAVE_NET  Process 

The  LEAVE^NET  process  shall  be  initiated  upon  command  of  the 
terminal  user  or  upon  command  from  the  network  via  a  maintenance 
message.  The  terminal  shall  signal  its  intention  to  leave  the  network 
by  issuing  the  following  sequence  of  messages: 

a.  It  shall  broadcast  a  SET_TOPOLOGY  message  to  the  network 
splicing  itself  from  ths  logical  ring. 

b.  It  shall  pass  the  token  to  CS  via  a  PASS_TOKEN_LEAVE_NET 
message . 

c.  It  shall  transition  to  the  OFF_LINE  state  after 
monitoring  to  assure  that  CS  has  picked  up  the  token. 

The  sequence  of  transmissions  shall  be  accommodated  using  a 
concatenated  message  structure,  using  a  single  token  hold  cycle.  It  is 
a  terminal  design  objective  to  provide  sufficient  locally  stored  power 
to  complete  the  LEAVEJNET  process  following  a  power  fault. 

3. 2. 1.4. 4. 1.9  COLD_START  Process 

The  COLD  START  process  shall  be  initiated  from  the  CLAIM_ 
TOKEN  state  whenever  the  token  has  been  claimed  and  the  topology  memory 
is  in  its  initial  state.  The  terminal  winning  the  token  sha'I  1  assume 
that  It  holds  the  highest  address  of  any  active  terminal  on  the  network 
and  declares  itself  to  be  the  ring  master  terminal.  The  ring  master 
shall  then  proceed  to  establish  the  logical  ring  as  illustrated  by 
Figure  16. 


a.  The  ring  master  shall  define  current  successor  (CS)  as  its 
own  address  (TA).  It  shall  set  Its  current  predecessor  (CP) 
and  its  potential  predecessor  (PP)  counter  to  l’A-1. 

b.  The  ring  master  shall  send  a  SOLICIT  ENTRY  message  to  PP  and 

wait  for  a  period  defined  by  the  RWT  for  a  response. 

c.  If  a  response  is  received  in  the  form  of  a  REQUEST  ENTRY 

message,  the  ring  master  shall  respond  with  a  SET_SUCCESSOR 
message  addressed  to  PP  listing  CS  as  successor, 

d.  The  ring  master  shall  send  a  SETJPREDECESSOR  message  to  CS 
listing  PP  as  predecessor. 

e.  The  ring  master  shall  replace  CS  with  PP  and  shall  decrement: 
PP  (PP  -  PP-l) . 

f.  Repeat  b  through  e  until  PP<0. 

g.  The  ring  master  shall  send  a  SETJPREDECESSOR  message  to  CS 
listing  TA  as  predecessor. 
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h.  The  ringmaster  shall  broadcast  a  SET  TOPOLOGY  message 
Including  the  physical  address  and  status  of  each  terminal 
residing  on  the  network. 

i.  The  ring  master  shall  transition  to  the  USE_T0K.EN  state. 
3.2.1.4.4.1.10  RESTART  Process 


The  RESTART  process  shall  be  initiated  from  the  CLAIM_TOKEN 
state  whenever  the  token  has  been  claimed  and  the  topology  memory  in 
the  ring  master  terminal  is  intact.  (Token  lost  and  not  recovered 
condition.)  The  following  process  shall  be  initiated: 

a.  The  ring  master  shall  poll  each  terminal  listed  as  ON-LINE  or 
0FF_JLINE  in  its  topology  memory  using  a  SQLICIT_REENTRY  token 
message . 

fc.  The  ring  master  shall  update  its  topology  memory  using  the 

results  of  the  poll.  Any  terminal  responding  with  a  REQUEST_ 
REENTRY  token  message,  shall  be  assumed  to  be  present  and 
active.  Terminals  not  responding  with  a  valid  response 
message  shall  be  assumed  OFFLINE. 

c.  The  ring  master,  at  the  conclusion  of  the  poll,  shall 
validate,  and  revise  if  necessary,  the  logical  ring  by 
splicing  out  any  OFFLINE  terminals  within  its  topology 
memory. 

d.  The  ring  master  shall  broadcast  a  SETJT0P0LOGY  message 
(if  required)  to  update  the  topology  memory  of  all  other 
terminals . 

e.  The  ring  master  shall  transition  to  the  USE__T0KEN  state  to 
re- initiate  normal  network  operation. 


3.2.1.4.4.1.11  Realtime  Clock  Management  Process 


rn\ -I ^.1 1- - -  - - ~ ~  ~ U  1  ^  4? 

me  t  ca  i.  l  ruic  u  i.  wuiv  uiana^cmuiit  p  t  uuc  d  j  ouux  x  ws  x  topuiiaat/xc  xvx 

coordinating  the  selection  of  one  terminal  to  act  as  network  timekeeper 
and  for  synchronization  and  drift  rate  correction  of  all  other  realtime 
clocks  to  the  timekeeper.  Any  terminal  within  the  network  may  be 
designated  by  its  user  process  as  the  timekeeper.  In  the  absence  of  a 
designated  timekeeper,  one  of  the  terminals  shall  assume  the  timekeeper 
function.  The  process  is  illustrated  by  figure  17. 


a.  Assuming  that  the  terminal  has  been  initialized  as  a 
not- timekeeper ,  the  RST  shall  be  initialized  to  TKF. 


b.  RST  shall  be  tested  to  see  if  it  has  expired.  If  not, 
the  process  shall  enter  a  wait  loop  until  either  RST 
expires  (error  case)  or  a  SET_RTC  message  is  received 
from  the  network  (normal  case). 


c.  Whenever  a  SET_RTC  message  is  received  from  the  network, 
the  RTC  shall  be  set  to  not- timekeeper  mode  of 
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operation,  the  RTC  shall  be  updated  from  the  SET_RTC 
data  field,  and  the  RTC  drift  rate  correction  factor 
(KRT)  shall  be  updated.  RST  shall  be  reset  to  TKF.  The 
process  shall  test  RST  as  described  in  section  b,  above. 

d.  Whenever  the  RST  expires,  the  RTC  shall  assume  that  no 
other  terminal  is  functioning  as  timekeeper  and  shall 
tentatively  assume  that  function.  The  RTC  shall  be 
tested  to  synchronize  with  the  FFFF  to  0000  rollover 
(65ms)  and  then  a  SET_RTC  message  shall  be  scheduled. 

If  a  SET_RTC  message  is  received  from  the  network  prior 
to  the  message  being  sent,  the  process  shall  revert  to 
not-  timekeeper  mode  of  operation  as  described  above. 

e.  If  the  SET_RTC  message  is  sent,  the  RTC  shall  set  itself 
to  timekeeper  mode  of  operation  and  shall  proceed  to 
generate  SETJRTC  messages  at  a  rate  defined  by  the 
initalization  value  TK. 

The  drift  rate  correction  algorithm  shall  be  implemented  as  an 
autonomous  function  of  each  terminal  using  the  algorithm: 

mnew  '  ^old  +  V2  <KRTold  -  KRTnew) 

Differential  delay  correction  shall  be  accomplished  by  the  user  process 
when  required  to  meet  system  RTC  accuracy  and  synchronization 
requirements . 

3.2.1.4.4.1.12  Redundant  Bus  Protocol 

Terminals  configured  for  operation  using  dual  redundant 
buses,  shall  meet  the  following  requirements  in  addition  to  those  of 
preceding  paragraphs.  The  general  approach  to  redundant  operation 
shall  be  for  terminals' to  transmit  and  receive  on  both  the  "A"  bus  and 
the  "B"  bus  at  all  times.  The  first  message  to  arrive  at  the  terminal 
("early"  bus)  shall  be  used  unless  a  data  error  occurs.  In  that  case, 
the  redundant  message  recovered  from  the  "late"  bus  shall  be  used. 

a.  Transmit  Operation.  Normally  a  terminal  shall  transmit 
both  messages  and  tokens  on  both  the  "A"  bus  and  the  "B" 
bus.  The  terminal  shall  modify  that  general  rule 
whenever  a  transmitter  failure  has  occurred  on  one  of 
the  output  ports  on  an  earlier  transmission  which  has 
not  been  cleared  by  BIT.  In  this  case,  the  terminal 
shall  transmit  on  the  non- error  port  alone. 

b.  Receive  Operation,  The  terminal  shall  monitor  both  RX 
ports  from  the  IDLE  state.  Messages  shall  be  recovered, 
buffered,  and  validated  from  both  the  "A"  bus  and  the 
"B"  bus.  The  terminal  shall  accept  the  message  from  the 
"early"  bus  unless  a  data  error  is  detected.  In  that 
case,  the  message  from  the  "late"  bus  shall  be  accepted 
if  valid.  The  decision  shall  be  independently  made 
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after  receipt  of  each  message  sub -block  ending  in  an 
FCS.  Receiver  errors  shall  be  separately  logged  for 
each  port. 

3. 2. 1.4. 4. 2  User  Interface  Machine  (UIM)  Description 

The  UIM  shall  act  as  the  intermediary  between  the  user 
process  and  the  other  elements  of  the  MAC  layer.  Its  internal 
operation  is  not  described  in  detail  in  this  specification  since  it 
depends  in  large  part  on  the  characteristics  of  the  specific  user 
process  being  interfaced  and  because  the  MAC  must  function  in 
accordance  with  the  requirements  of  this  specification  no  matter  what 
method  of  implementing  the  UIM  is  elected.  The  UIM  shall  provide 
three  different  modes  of  operation,  initialization,  steady  state 
operation,  and  maintenance. 

During  initialization,  while  the  terminal  is  still  in  the 
OFF  LINE  state,  terminal  operating  parameters  may  be  loaded  into  the 
UIM  via  the  TMU  function.  Parameters  shall  include: 

a.  Network  topology  memory 

b. .  RWT  initial  value 

c.  THT  Initial  value 

d.  TRT-P1  initial  value 

e.  TRT-P2  initial  value 

f.  TRT-P3  initial  value 

p.  RMT  initial  value 

h.  SET  initial  value 

1.  RLT  initial  value 

k.  NIT  initial  value 

l.  RST  initial  value 

As  an  option,  the  system/terminal  designer  may  elect  to  use  preset 
operating  parameters.  In  this  case,  the  logical  ring  may  be 
established  without  initiation  by  the  user.  Once  the  terminal  has 
entered  the  logical  ring,  the  values  of  the  operating  parameters  may  be 
changed  via  a  terminal  maintenance  message  received  from  the  network  or 
by  the  user. 

During  steady  state  operation,  the  function  of  the  UIM  is  to 
facilitate  the  transfer  of  data  into  and  out  of  the  terminal.  This 
shall  be  accomplished  in  accordance  with  the  requirements  of  paragraph 
3. 1.5.1. 


Maintenance  operations  shall  be  initiated  at  the  discretion 
of  the  user.  Terminal  operating  parameters  may  be  verified  and/or 
modified.  The  terminal  may  be  polled  for  statistics  related  to 
operation  of  the  terminal  or  the  network.  As  a  minimum,  the 
characteristics  described  in  Table  XI  shall  be  computed  within  the  UIM 
of  each  terminal. 

It  shall  be  possible  to  request  the  identical  maintenance 
characteristics  from  any  remote  terminal  In  the  network  by  transmission 
of  a  properly  formatted  terminal  maintenance  message.  Similarly,  it 
shall  be  possible  to  command  any  remote  terminal  in  the  network  to 
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retransmit  maintenance  loopback  messages  back  to  the  requesting 
terminal. 

3. 2. 1.4. 4. 3  Receive  Machine  Description 

The  receive  (RX)  machine  shall  accept  RXM  from  the  PHY  layer 
and  shall  generate  data  structures  and  signals  for  the  MAC  layer  APM 
and  UIM.  Figure  18  describes  the  process  which  shall  be  implemented  by 
the  Rx  machine.  Note  that  for  dual  redundant  terminals  the  process  is 
duplicated  for  both  the  "A"  bus  and  the  "B"  bus.  The  message  from  the 
"early"  bus  shall  be  accepted  unless  FCS  validation  fails. 

The  following  approach  is  suggested  in  order  to  minimize, 
terminal  response  time.  Alternative  approaches  are  allowed  so  long  as 
all  performance  requirements  are  met. 

The  RXM  is  decomposed  into  its  component  fields  as  it  is 
received.  Appropriate  responses  are  buffered  in  both  ports  of  the  Rx. 
machine  prior  to  the  complete  message  being  clocked  into  the  machine. 
Action  is  deferred  until  the  final  bit  has  been  received  and  the  FCS 
has  been  validated.  At  this  point,  the  decision  as  to  whether  to  use 
the  "A"  buffers  of  the  "B"  buffers  is  made  on  the  basis  of  FCS 
validation.  The  "early"  message,  has  precedence.  Hie  FCS  is  reset 
immediately  following  receipt  of  the  last  bit  of  each  data  block  so 
that  successive  256  word  data  blocks  may  be  tested  independent  of  each 
other. 

3. 2. 1.4. 4. 4  Transmit  Machine  Description 

The  transmit  (Tx)  machine  shall  accept  TXC  and  TXD  from  the 
ACM  and  UIM  respectively  and  shall  generate  TXM  for  presentation  to  the 
PHY  layer.  TXU  shall  be  sent  first  followed  by  TXD.  FCS  shall  be 
appended  to  the  end  of  TXD  to  form  the  composite  TXM.  For  data 
messages  greater  than  256  words,  the  message  shall  be  decomposed  into  a 
number  of  256  word  or  remainder  fields  and  shall  be  transmitted  with  a 
FCS  field  appended  to  each. 

Figure  15  describes  a  suggested  approach  to  design  of  the  Tx 
machine.  The  approach  is  suggested  as  appropriate  in  order  to  minimize 
terminal  response  time.  Alternative  approaches  are  allowed  so  long  as 
all  performance  requirements  are  met. 

Transmission  is  initiated  via  TXC  whenever  the  terminal 
receives  a  message  requiring  a  transmission  response.  The  APM  assumes 
that  FCS  will  be  validated  and  begins  to  transmit  PRE  +  SD.  If  FCS 
does  not  validate,  the  ABORT  sequence  is  transmitted.  If  the  FCS  does 
validate,  the  Tx  machine  continues  the  transmission  by  sending  the 
scheduled  FC  +  DA  +  SA  +  WC  +  data  +  FCS  sequence.  FCS  is  generated 
for  each  256  words  and  appended  to  the  data  field  in  realtime. 

3. 2. 1.5  Error  Recognition  and  Recovery 

The  HSDB  shall  include  design  features  which  limit  the  impact 
of  failure  mechanisms.  No  single  failure  shall  be  capable  of  disabling 
the  entire  network.  Each  terminal  shall  have  the  capability  to 
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recognize  all  errors  defined  by  Table  XVII  and  to  recover  from  the 
error  state  in  the  manner  described.  The  general  error  handling 
approach  shall  be  to  treat  received  messages  which  do  not  meet  all 
quality  tests  as  noise;  the  sending  terminal  shall  be  responsible  for 
recovery  from  a  lost  token  or  multiple  token  condition;  and  each 
terminal  shall  contain  embedded  features  which  prevent  long  term 
corruption  of  the  bus, 

TABLE  XVII 

ERROR  RECOGNITION  AND  RECOVERY 


Error  Condition 


znition 


Recovery  Strategy 


Massage  date  field 
corrupted  on  bus 
Message  DA  field 
corrupted  on  bus 
Message  FC  field 
corrupted  on  bus 
Message  token  field 
corrupted  on  bus 
Message  preamble 
corrupted  on  bus 
Message  SD  field 
corrupted  on  bus 
Message  F.D  field 
corrupted  on  bus 
Message  SA  field 
corrupted  on  bus 
Terminal  failure  - 
not  holding  token 
Terminal  failure  - 
holding  token 
Terminal  transmitter 
stuck  'or.' 

Terminal  receiver 
defective 

Terminal  transmitter 
defective 

rn _ J _ l  _1  -  .1.  t  .  1 
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or  low  freq 
Terminal  receiver 
low  sensitivity 
Terminal  transmitter 
low  output 
Terminal  address 
duplicate 
Terminal  address 
intermittent 
All/most  terminals 

off-line  concurrently 
Bus  broken  -  redundant 
bus  topology 
Bus  broken  -  single 
bus  topology 


Receiver  Data  error 
Receiver  Data  error 
Receiver  Data  error 
Token  lost  error 


Message  discarded 

Message  discarded 

Message  discarded 
Recover  token 
Process 


Receiver  sync,  error  Message  lost 

Receiver  framing  error  Message  lost 

Receiver  WC  and 

framing  error  Message  accepted 

Receiver  Data  error  Message  discarded 

Recover  token 

Token  lost  error  Process 

WARM_RESTART 

Bus  activity  error  Process 

WARM_RESTART 

Token  hold  error  Process 

Terminal  goes 

Net  initialize  error  off-line 

Terminal  goes 

Transmitter  error  off-line 

Terminal  goes 

Receiver  sync  error  off-line 

Receive  only 

Receiver  error  operation 

Receiver  only 

Transmitter  error  operation 

Token  error  (multiple)  Message  discarded 


Multiple/lost  token  error 
Bus  activity  error 
Bus  activity  error 
Bus  activity  error 


Retry 

C0LD_RESTART 

process 

SWITCH_BUS 

process 

WARM/COLD_RESTART 

process 
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3. 2.1. 5.1  Recognition  Strategies 

The  general  strategy  for  error  recognition  shall  be  for  each 
terminal  t  >  use  all  information  available  from  past  network  activity  to 
infer  the  health  state  of  itself  and  of  the  network  in  total.  Error 
counters  included  in  each  terminal  shall  accumulate  detected  errors 
for  maintenance  status  reporting. 

3. 2. 1.5. 1.1  Receiver  Data  Error 

The  receiver  data  test  function  shall  signal  if  FCS  or 
Manchester  bit  errors  occurred  between  the  SD  and  the  ED  fields  of  the 
received  message.  In  all  cases,  the  message  shall  be  discarded  by  the 
receiving  terminal.  The  data  error  counter  shall  be  incremented  for 
each  detected  FCS  error  or  Manchester  error. 

3. 2. 1.5. 1.2  Token  Lost  Error 

In  the  case  where  a  discarded  message  contained  the  token, 
the  sending  terminal  shall  recognize  that  the  token  was  lost  and  shall 
initiate  the  recovery  procedure.  The  token  lost  error  counter  shall 
be  incremented  for  each  detected  token  lost  error. 

3. 2. 1.5. 1.3  Receiver  Synchronization  Error 

The  receiver  clock  synchronization  test  function  shall  signal 
if  the  terminal  clock  failed  to  synchronize  to  the  received  message  or 
lost  synchronization  during  receipt  of  the  message.  In  all  cases,  the 
message  shall  be  discarded  by  the  receiving  terminal.  The  receive  sync 
error  counter  shall  be  incremented  for  each  detected  sync  error. 

3 . 2 . 1 . 5 . 1 . 4  Rece iver  Framing  Error 

The  receiver-framing  error  test  function  shall  signal  if  the 
terminal  received  a  message  which  was  not  properly  framed  by  SD  and  ED 
fields.  If  all  other  quality  tests  pass,  the  message  shall  be  accepted 
as  valid  by  the  terminal.  In  all  cases,  the  framing  error  counter  shall 
be ' incremented  for  each  detected  framing  error. 

3. 2. 1.5. 1.5  Word  Count  Error 

The  receiver  word  count  error  test  function  shall  signal  if 
the  terminal  received  a  message  in  which  the  value  in  the  word  count 
field  did  not  match  the  number  of  words  In  the  data  field.  The  word 
count  error  counter  shall  be  incremented  for  each  detected  word  count 
error . 

3. 2. 1.5. l.o  Deleted 


3. 2. 1.5. 1.7  Bus  Activity  Error 

Whenever  the  NIT  expires,  the  receiver  shall  signs L  a  bus 
activity  error  and  shall  Increment  the  bus  activity  error  counter. 
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3 . 2 . 1 . 5 . 1 . 8  Token  Hold  Error 

A  token  hold  error  shall  be  signaled  If  the  terminal  receiver 
functlon  detects  that  the  transmitter  hAs  been  active  for  a  period 
greater  than  the  THT  allows  or  if  the  watchdog  tinier  expires.  In  the 
former  case,  the  terminal  shall  terminate  the  transmission  with  an 
abort  sequence  as  described  in  3. 2. 1.1.  In  either  case,  the  terminal 

shall  initiate  an  error  shutdown  sequence  and  shall  go  off-line.  The 
token  hold  error  counter  shall  be  incremented  at  each  occurrence  of  a 
token  hold  error. 

3. 2. 1.5. 1.9  Network  Initialize  Error 

The  network  initialize  error  state  shall  be.  recognized 
whenever  the  terminal  attempts  to  establish  the  logical  ring  via  the 
initialization  process  but  fails  to  find  a  successor  terminal.  The 
terminal  shall  assume  that  either  its  receiver  is  inactive  or  else  it 
is  alone  on  the  network  and  shall  go  off-line.  The  network  initialize 
error  counter  shall  he  incremented  at  each  occurrence  of  initialise 
error. 

3.2.1.5.1.10  Transmitter  Error 

A  transmitter  error  shall  be  signaled  whenever  the  terminal 
receiver  does  not  recover  a  loopback  signal  of  expected  amplitude  and 
with  correctly  encoded  data  from  its  companion  transmitter  and  is  not 
in  a  receiver  error  state.  The  terminal  shall  set  that  transmitter 
port  to  "inactive"  status  and  shall  record  that  fact  in  its  topology 
memory.  Should  that  port  be  the  only  active  transmit  pert  of  the 
terminal,  it  shall  abort  the  transmission  with  a  valid  abort  sequence 
and  shall  go  off-line.  Should  an  active  transmit  port  remain,  the 
terminal  shall  enter  a  T0P0LQGY_MESSAGE  into  its  transmit  queue  to 
affect  a  broadcast  of  its  change  in  status  and  shall  continue  its 
present  T0KEN__H0LD  cycle  as  if  the  error  had  not  occurred.  The 
transmitter  error  counter  shall  be  incremented  at  each  occurrence  of 
transmitter  error. 

3.2.1.5.1.11  Receiver  Error 
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receiver  fails  to  recover  three  successive  packets  from  the  network 
which  are  error  free  (Manchester  error,  FCS  error,  or  framing  error). 
Should  a  receive  error  state  exist,  the  terminal  shall  set  that  receive 
port  to  inactive  status  and  shall  record  that  fact  in  Its  topology 
memory.  It  shall  also  enter  a  TOPOLQG'Y_KESSAGE  into  its  transmit  queue 
to  affect  a  broadcast  of  its  change  in  status.  Should  that  port  be  the 
only  active  receive  port  of  the  terminal,  it  shall  go  off-line.  The 
receive  error  counter  shall  be  incremented  at  each  occurrence  of 
receiver  error. 


3.2.1.5.1.12  Token  Error 


If  a  terminal  receives  a  token  from  the  network  with  the  GA 
different  from  that  listed  as  its  predecessor  in  the  topology  memory, 
the  terminal  shall  assume  that  a  multiple  token  exists  and  shall  not 
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respond.  The  token  error  counter  shall  be  Incremented  at  each 
occurrence  of  a  multiple  token  error.  The  terminal  shall  retain  its 
position  in  the  logical  ring. 

If  a  terminal  recognizes  a  coken  on  the  network  with  SA  — 
its  PA  and  DA  ?  TA,  it  shall  assume  that  its  topology  memory  is 
defective  and  shall  not  transition  to  USE_T0KEN  state.  It  shall  enter 
a  REP0RT_T0P0L0GY_MEM0RY  message  addressed  to  the  ring  master  terminal. 
The  token  error  counter  shall  be  incremented  at  each  occurrence. 

3. 2. 1.5. 2  Recovery  Strategy 

HSDB  terminals  shall  support  a  hierarchy  of  recovery 

processes . 

1st  -  Alternate  bus 
2nd  -  Retry 
3rd  -  Recover  token 
4th  -  Restart 

The  design  objective  is  to  cause  a  minimum  disruption  to  the 
network  under  failure/error  conditions.  Messages  which  are  corrupted 
on  the  network  and  received  as  defective  shall  be  abandoned  (lost). 

The  terminal  protocol  shall  contain  features  which  recover  from  lost- 
token  messages.  The  user  shal 1  be  responsible  for  determining  which 
messages  are  critical  to  system  operation  and  for  instituting  recovery 
of  lost  data  messages  and  maintenance  messages  except  in  instances 
specifically  defined  elsewhere  in  this  specification. 

3. 2. 1.5. 2.1  Alternate  Bus  Procedure 

The  alternate  bus  shall  be  used  as  the  first  attempt  at 
recovery  of  a  lost  message.  Each  terminal  shall  monitor  both  RX  ports. 
Messages  shall  be  recovered  and  buffered  from  both  the  "A"  bus  port  and 
the  "B"  bus  port.  Each  terminal  shall  accept  the  message  from  the 
earliest  arriving  message  ("early"  message)  unless  a  data  error  is 
detected.  In  the  event  of  a  data  error  on  the  "early"  bus  port,  the 
message  from  the  other  (i:iate:i)  po.  t  shall  be  accepted  unless  it  too 
contained  a  data  error. 

3. 2. 1.5. 2. 2  Retry  Procedure 

Retry  shall  be  automatically  initiated  for  lost  token 
messages  only.  Each  terminal  shall  contain  design  features  which 
implement  the  following  retry  strategy: 

a.  The  token  sending  terminal  shall  monitor  the  network  for  a 
period  of  time  Immediately  fol  lowing  its  transmission  of  a 
token  message. 

b.  If  after  RWT,  the  sending  terminal  does  not  recognize  the 
pattern  "PRE  4  SD  t  FC”  on  the  network,  it  shall  assume  that, 
the  token  has  been  lost  during  transmission  and  shall  retry 
the  token  pass. 
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c.  The  sending  terminal  shall  retry  a  maximum  of  RLT  times  to 
pass  the  token.  If  not  successful,  the  terminal  shall 
assume  that  the  intended  successor  terminal  has  failed  and 
shall  institute  token  recovery  procedures. 

3 . 2 . 1 . 5 . 2 , 3  Recover  Token  Procedure 

The  recover  token  procedure  shall  be  automatically  initiated 
whenever  (A)  the  intended  successor  terminal  has  failed  prior  to 
accepting  the  token,  or  (B)  the  token  holding  terminal  has  failed 
while  in  possession  of  the  token.  Each  terminal  shall  contain  design 
features  which  implement  the  following  token  recovery  strategy. 

Case  A:  Case  A  shall  be  initiated  by  the  token  holding 
terminal  upon  unsuccessful  completion  of  the  retry  strategy. 
Four  activities  shall  be  accomplished  in  the  sequence  defined 
below. 

a.  The  terminal  shall  modify  its  topology  memory  to 
splice  around  its  present  (failed)  successor. 

b.  The  terminal  shall  broadcast  the  changed  topology 
memory  to  the  network  via  a  SET_T0P0LQGY_M EMORY 
message . 

c.  The  terminal  shall  pass  the  token  to  its  new 

SUCC£SSOiT  . 

d.  The  terminal  shall  attempt  to  recover  the  token  a 
maximum  of  RLT  times.  If  not  successful ,  the 
terminal  shall  assume  that  its  own  receiver  has 
failed  and  shall  transition  to  the  off-line  state. 

Case  B:  Case  B  shall  be  initiated  by  the  predecessor 
terminal  of  the  terminal  which  held  (lost)  the  token.  Each 
terminal  shall  monitor  the  entire  token  hold  cycle  of  its 
successor  to  ensure  that  the  token  is  passed  (to  successor's 
successor).  Five  activities  shall  be  accomplished  in  the 
sequence  defined  below. 

a.  If  the  last  message  transmitted  as  part  of 
successors  packet  was  not  recognized  as  a  token 
message,  the  terminal  shall  continue  to  monitor 
the  network  for  RWT. 

b.  If  after  RWT  the  terminal  does  not  recognize  the 
pattern  "PRE  4  SD  •»  FC"  on  the  network,  it  shall 
assume  that  the  token  holder  has  failed. 

c.  Hie  terminal  shall  modify  Its  topology  memory  to 
splice  around  its  present  (failed)  successor. 

d.  Hie  terminal  shall  broadcast  the  changed  topology 
memory  to  the  network  via  a  SET_T0P0L0GY_MEM0IIY 
message . 
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e ,  The  terminal  shall  pass  the  token  to  its  new 
successor , 

If  the  terminal  recognizes  valid  network  activity  during  RWT,  it  shall 
assume  that  its  own  receiver  lost  the  token  message  ami  shall  remain 
quiescent. 

3 . 2 . 1 . 5 . 2 . 4  Res  tar  t 

Restart  shall  be  automatic  whenever  the  token  has  been  lost 
and  is  not  recoverable  by  the  alternate  bus,  retry,  or  recover  token 
procedures.  Each  terminal  shall  contain  design  features  in  accordance 
with  the  restart  requirements  of  3.2.1,4.4.1,10. 

3.2.2  Phy s leal  Char ac teristies 

Physical  characteristics  shall  be  defined  by  specifications 
associated  with  specific  systems  applications  and  specific  hardware 
components . 

3.2.3  Reliability  (No  requirement) 

3.2.4  Maintainability  (No  requirement) 

3.2.5  Availability  (No  requirement) 

3.2.6  System  Effectiveness  Models  (No  requirement) 

3.2.7  Environmental  Conditions 

The  HSDR  and  components  thereof  shall  be  designed  to 
withstand  the  extremes  of  a  MIL-E-5400,  Class  II  temperature 
environment  without  sustaining  damage  or  degraded  operation. 

3.2.8  Nuclear  Control  Requirements  (No  requirement) 

3.2.9  Transportability  (No  requirement) 

3.3  Design  and  Construction 

MJL-E-5400T  shall  be  used  as  a  guideline  for  the  design  of 
HSDB  hurdware  components . 

3.3.1  Materials,  Proteoses,  and  Parts 

HSDR  hardware  components  shall  be  designed  using  materials, 
processes,  and  parts  selected  to  be  In  accordance  with  the  requirements 
of  M1L-E-5400T,  paragraph  3.1  through  3.1.58  to  the  maximum  extent 
practical . 

3.3.2  Electromagnetic  Radiation  (Wo  requirement) 
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3.3.3  Nameplates  and  Product  Harkings 

HSDB  assemblies  shall  be  Individually  identified  and  marked 
with  an  unique  Collins  parts  number  and  serial  number. 

3.3.4  Workmanship 

Workmanship  shall  be  inspected  to  be  in  general  accordance 
with  the  requirements  of  MIL  J-5400T,  paragraph  3.5. 

3.3.5  Interchangeability 

Wherever  practical,  like  part  numbered  assemblies  and 
subassemblies  shall  be  interchangeable  mechanically  and  electrically 
without  adjustment  of  that  or  other  system  components. 

3.3.6  Safety 

The  HSDB  and  components  thereof  shall  be  designed  using  the 
requirements  of  MIL-E-5400T,  paragraph  3.2.22  as  a  guideline. 

3.3.7  Human  Performance/Human  Engineering  (No  requirement) 

3.4  Documentation 

Documentation  of  the  HSDB  system  and  components  thereof  shall 
conform  to  the  requirements  of  DoD-D-1000. 

3.5  Logistics  (No  requirement) 

3.6  Personnel  and  Training  (No  requirement) 

3.7  Functional  Area  Characteristics 

A  coaxial  HSDB  system  shall  be  comprised  of  coax  bus 
terminal,  coupler,  mainbus,  stub  bus,  and  termination  assemblies  as 
illustrated  by  figure  20a.  A  FO  HSDB  system  shall  be  comprised  of  a 
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illustrated  by  figure  20b. 

3.7.1  Coaxial  Bus  Function  Descriptions 

3. 7. 1.1  Coax  Bus  Terminal 

The  coax  bus  terminal  function  is  responsible  for 
establishing  communication  paths  between  user  functions  via  the  HSDB 
network  and  for  organization  of  data  for  transport  between  users.  The 
terminal  function  shall  be  designed  using  a  combination  of  hardware 
and  software  subfunctionc  to  perform  as.  described  by  paragraph  3.2  of 
this  specification.  The  interface  with  the  user  process  shall  meet  the 
requirements  of  paragraph  3. 1.5,1.  Tl.e  interface  with  the  coupler 
shall  meet  the  requirements  of  3. 7. 5. 2. 
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FIGURE  20a 

COAXIAL  HSDB  SYSTEM  FUNCTIONAL  PARTITIONING 
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3 . 7 . 1 . 2  Coupler 

The  coax  bus  coupler  function  allows  physical  and  electrical 
access  to  the  bus  media  (coaxial  cable)  by  the  terminal.  The  coupler 
function  shall  be  comprised  of  a  hardware  assembly  meeting  the 
requirements  of  paragraph  3.2.1.2.1-e  through  3. 2, 1.2. 1-1.  The 
interface  with  the  terminal  function  shall  meet  the  requirements  of 
3. 1.5. 2.1,  3. 1.5. 2. 2,  and  3. 1.5.2. 3.  The  interface  with  the  mainbus 
shall  meet  the  requirements  of  3. 1.5. 2. 4  (2  ports,  input  and 
output) . 

3 . 7 . 1 . 3  Mainbus 

The  mainbus  function  allows  couplers  (and  terminals)  to  be 
physically  separated  by  a  maximum  of  300  feet.  The  mainbus  shall  be 
comprised  of  a  set  of  coaxial  cable  assemblies  meeting  the  requirements 

3.2.1.2.1- e,  and  3.2.1,2.1-f  (less  coupler  mainbus  loss).  The 
interfaces  with  the  couplers  shall  meet  the  requirements  of  3. 1.5. 2. 4. 

3. 7. 1.4  Stub  Bus 

The  stub  bus  function  allows  terminals  to  be  physically 
separated  from  couplers  by  a  maximum  of  20  feet.  The  stub  bus  shall  be 
comprised  of  a  set  of  coaxial  cable  assemblies  meeting  the  requirements 

3.2.1.2.1- a  through  3.2.1.2.1-d.  The  interfaces  shall  meet  the 
requirements  of  3. 1.5. 2.1  through  3. 1.5. 2. 3. 

3 . 7 . 1 . 5  Termination 

The  termination  function  is  used  at  each  physical  extremity 
of  the  network  to  provide  an  ideal  impedance  at  the  unused  mainbus  port 
of  the  last  coupler.  The  characteristic  impedance  shall  be  50+J0  ohms 
+TBS  ohms.  The  interface  shall  consist  of  a  male  type  TNC  connector. 

3.7.2  Fiber  Optic  Bus  Function  Descriptions 

3. 7. 2.1  Fiber  Optic  Bus  Terminal 

The  fiber  optic  (F0)  bus  terminal  function  is  responsible  for 
establishing  communications  paths  between  user  functions  via  the  HSDB 
network  and  for  organization  of  data  for  transport  between  users.  The 
terminal  function  shall  be  designed  using  a  combination  of  hardware  and 
software  subfunctions  to  perform  as  described  by  paragraph  3.2  of  this 
specification.  The  interface  with  the  user  process  shall  meet  the 
requirements  of  3  1.5.1.  The  interface  with  the  star  coupler  shall 
meet  the  requirements  of  3. 1.5. 3. 

3. 7. 2. 2  Star  Coupler 

The  star  coupler  function  allows  optical  interconnection  of 
the  terminals  comprising  the  network.  The  coupler  shall  be  comprised 
of  a  single  hardware  assembly  meeting  the  requirements  of  3.2.1.2.2-b 
through  3. 2. 1.2. 2 -f.  The  interface  shall  meet  the  requirements  of 

3. 1.5. 3  (each  of  64  ports). 
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3. 7. 2. 3  Fiber  Stub 

The  fiber  stub  function  allows  terminals  to  be  physically 
separated  from  the  star  coupler  by  a  maximum  of  300  feet.  The  fiber 
stub  shall  be  comprised  of  a  set  of  fiber  optic  cables  terminated  at 
each  end  by  either  &  connector  or  a  splice,  and  shall  meet  the 
requirements  of  3.2.1.2.2-e  and  3.2.1.2.2-e  through  3.2,1.2.2-£.  The 
interface  at  the  terminal  end  shall  meet  the  requirements  of  3, 1.5. 3. 

3. 7. 2. 4  Attenuator 

The  attenuator  function  allows  terminals  in  low  loss  paths  of 
the  network  to  avoid  saturation  of  the  terminal  receiver  by  lowering 
the  optical  power  prior  to  application  to  the  terminal.  The 
attenuation  shall  be  specified  by  the  system  designer  at  a  value 
appropriate  for  this  purpose  given  the  specific  characteristics  of  the 
network  under  development.  Interface  with  the  fiber  stub  shall  be  via 
splice  or  optical  SMA  type  connectors  at  the  discretion  of  the  system 
designer. 


3.8  Precedence 

Not  Applicable 

4  .  QUALITY  ASSURANCE  PROVISIONS 

Requirements  for  formal  tests/verifications  of  system 
performance  design  characteristics  shall  be  specified  by  the 
development  specifications  of  individual  systems:  and  system  components. 

5.  PREPARATIONS  FOR  DELIVERY  (Not  required) 

6.  NOTES 

6.1.  The  user  interface  to  the  terminal  is  purposely  specified  in 

a  general  manner  so  as  to  allow  interface  to  e  variety  of  different: 
users  in  an  optimum  manner.  Some  interfaces  may  be  implemented  using, 
serial  data  paths,  others  using  parallel,  tor  example.  The 
development  specification  of  each  terminal/user  must  specify  this 
interface  in  detail. 
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GLOSSARY  OF  ACRONYMS 

Acronym  Description 

Definition 

APM 

Access  and  Protocol  Machine 

3. 2. 1.4. 3.1 

CRU 

Configuration  Reporting  Unit 

3.2.1.4.1.11 

CS 

Current  Successor  Address 

3. 2. 1.4. 4. 1.9 

CP 

Current  Predecessor  Address 

3. 2. 1.4. 4. 1.9 

DA 

Destination  Address 

3.2.1. 1.5 

ED 

End  Delimiter 

3. 2. 1.1. 9 

FI 

TRT  PI  Flag 

3. 2. 1.4. 4. 1.3 

F2 

TRT  P2  Flag 

3. 2. 1.4. 4. 1.3 

F3 

TRTJP3  Flag 

3. 2. 1.4. 4. 1.3 

FC 

Frame  Control 

3. 2. 1.1. 3 

FCS 

Frame  Check  Sequence 

3. 2. 1.1. 6 

FIFO 

First -In- First -Out 

FO 

Fiber  Optic 

HSDB 

High  Speed  Data  Bus 

KRT 

RTC  Drift  Rate  Correction 

3.2.1.4.4.1.11 

LS 

Logical  Successor 

MAC 

Media  Access  Control  Layer 

3.2. 1.4 

MED 

Media  Layer 

3. 2. 1.2 

NIT 

Network  Inactivity  Timer 

3.2. 1.4. 3. 5 

FO 

Highest  Priority 

FI 

Intermediate  Priority 

P2 

Lowest  Priority 

U  4 
*■  -> 

,  f»_  J _ .1  - 

rnuiiLy 

PHY 

Physical  Layer 

3.2. 1.3 

PP 

Potential  Predecessor 

3.2. 1.4.4. 1.9 

FRE 

Preamble 

3 . 2 . 1 . 1 . 1 

PS 

Potential  Successor 

3. 2. 1.4. 4. 1.7 

RLT 

Retry  Limit  Timer 

3. 2. 1.4. 3. 7 

RMT 

Ring  Maintenance  Timer 

3.2. 1.4. 3. 3 

RST 

Realtime  Clock  Synchronism  Timer 

3 . 2 . 1 . 4 . 3 . 8 

rtc 

Realtime  Clock 

3. 2. 1.4. 2. 7 

RUT 

Response  Window  Timer 

3. 2. 1.4. 3. 6 

RX 

Receive 

RXC 

Receive  Control  Unit 

32.1.4  1  9 

RXD 

Receive  Data  Unit 

3.2. 1.4.1. 8 

RXM 

Receive  Message 

3. 2. 1.4. 1.7 

RXU 

Receive.  Unit 

3.1.5.1/3.2.1.4.1.10 

SA 

Source  Address 

3 . 2 . 1 . 1 . 4 

SD 

Start  Delimiter 

3. 2. 1.1. 2 

SET 

Solicit  Entry  Timer 

3.2. 1.4. 3.4 

TA 

Terminal  Address 

TCU 

Terminal  Control  Unit 

3. 2. 1.4. 1.5 

THT 

Token  Hold  Timer 

3.2. 1.4. 3.1 

TK 

Timekeeper 

3. 2. 1.4. 3. 8 

TKF 

Not  Timekeeper 

3. 2. 1.4. 3. 8 

TMU 

Terminal  Management  Unit 

3. 1.5. 1/3. 2. 1.4. 1.2 

TRT 

Token  Rotation  Timer 

3. 2. 1.4. 3. 2 

TRU 

Transmit/Receive  Unit 

3.2.1.3.n 

TSU 

Terminal  Status  Unit 

3.1.5.1/3.2.1.4.1.12 

TX 

Transmit 

TXC 

*ransmit  Control  Unit 

3. 2. 1.4. 1.4 

0-  76 


SPA  90099011A 
16  January  1987 


GLOSSARY  OF  ACRONYMS  (Cont'd) 


Description 


Definition 


Transmit  Data  Unit 

3. 2. 1.4. 1.3 

Transmit  Message 

3. 2. 1.4, 1.6 

.'vp 

Transmit  Unit 

3. 1.5. 1/3. 2. 1.4. 1.1 

User  Interface  Machine 

3. 2. 1.4. 3. 2 

Word  Count 

3. 2. 1.1. 6 
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PI -Bus  Interface  Design  Guide 

20.1  Scope 

This  appendix  to  the  HSDB  System  Specification  Illustrates  an 
approach  which  may  be  used  to  interface  the  HSDB  to  a  PI -Bus.  The  PI- 
Bus  was  chosen  due  to  its  potential  for  wide  application  throughout 
military  aircraft  as  a  backplane  bus. 

20 . 2  Requirements 

The  user  interface  requirements  of  a  HSDB  terminal  are 
described  in  paragraph  3. 1.5.1.  PI -Bus  interface  requirements  are 

described  in  the  PI -Bus  specification. 

20.2.1  Transmit  Operation 

The  transmit  operation  is  defined  as  the  process  required  for 
a  ?I-Bus  module  to  place  a  message  on  the  HSDB.  The  operation  consists 
of  the  set  of  transactions  described  in  Table  I.  The  SEQuence  column 
identifies  the  transaction  sequence  described  in  the  HSDB  System 
Specification.  The  SOURCE  column  identifies  the  PI -Bus  module  which 
wishes  to  originate  the  message.  The  DESTination  column  is  the  Pi-Bus 
module  which  has  direct  Interface  (gateway)  to  the  HSDB.  MESSage 
refers  to  the  message  sequence  type  as  described  in  the  PI -Bus 
specification.  Note  that  it  is  assumed  that  the  SOURCE  module  is  PI- 
Bus  master  at  initiation  of  the  operation. 


TABLE  I 

TRANSMIT  OPERATION 


SEQ 

SOURCE 

DEST 

MESS 

NOTES 

l(TMU) 

- - - 

--> 

BUS  INTERFACE  MESSAGE 

a. 

2(TSU) 

< - 

.  -* 

PARAMETER  WRITE 

b. 

3 (TXU) 

* . 

--> 

BUS  INTERFACE  MESSAGE 

OR  BLOCK  MESSAGE 

c . 

4(TMU) 

* . 

--> 

PARAMETER  WRITE 

d. 

NOTES : 

* 

PI -Bus  Master 

--> 

Information  Des 

tination 

a. 

Request  to  send,  word  count,  class  of  service,  des 

tination 

address  and  subaddress, 

priority 

b. 

Buffer  address 

or  error/busy  indication 

c . 

Data  field  contents 

d. 

Confirmation  or 

'  abort 

20.2.2  Receive  Operation 

The  receive  operation  is  defined  as  the  process  required  for 
a  PI -Bus  module  to  recover  a  message  from  the  HSDB.  The  operation 
consists  of  the  set  of  transactions  described  in  Table  II.  The 
SEQuence  column  identified  the  transaction  sequence  described  In 
the  HSDB  system  specification.  The  SOURCE  column  identifies  the 
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PI -Bus  nodule  which  has  direct  access  to  the  HSDB.  The  DESTination 
column  Is  the  ?I-Bus  module  for  which  the  message,  is  intended. 

Note  that  it  is  assumed  that  the  SOURCE  module  is  PI -Bus  master  at 
initiation  of  the  operation.  The  £(ESSage  column  refers  to  the 
message  sequence  type  as  described  in  the  PI -Bus  specification. 

TABLE  II 

RECEIVE  OPERATION 


SEQ  SOURCE  PEST  MESS _  NOTES 

l(TSU)  * . >  BUS  INTERFACE  MESSAGE  a. 

2(RXU)  . - . >*  BUS  INTERFACE  MESSAGE 

OR  BLOCK  MESSAGE  b. 

3(TMU)  < . *  PARAMETER  WRITE  c. 


NOTES : 

*  PI -Bus  Master 

-->  Information  destination 

a.  Word  count,  location  of  buffer,  source  address,  class  of 
service,  priority 

b.  Data  field  contents 

c.  Confirmation  (free  buffer) 

20.2.3  Status  Request  Operation 

The  status  request  operation  is  defined  as  the  process  by 
which  a  PI -Bus  module  may  request  status  information  from  either  the 
local  HSDB  interface  module  or  of  some  other  terminal  of  the  HSDB.  The 
operation  consists  of  the  set  of  transactions  listed  on  Table  III.  The 
SOURCE  column  identifies  the  PI -Bus  module  which  originates  the  status 
request.  The  PEST  column  identifies  the  PI -Bus  module  having  direct 
access  to  the  HSDB. 

TABLE  III 

STATUS  REQUEST  OPERATION 


SOURCE  PEST  MESS  _  NOTES 


1  (THU)  * . - . >  BUS  INTERFACE  MESSAGE 

2(TSU)  < . *  BUS  INTERFACE  MESSAGE 

3CEXU)  *< .  BUS  INTERFACE  MESSAGE 

OR  BLOCK  MESSAGE 

U (THU)  * . . >  PARAMETER  WRITE 


NOTES : 

*  PI -Bus  master 

-->  Information  destination 

a.  Status  request,  parameter (s) ,  source  address 

b.  Word  count,  location  of  buffer,  source,  class  of  service 

c.  Status  message 

d.  Confirmation  (free  buffer) 
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20.2.4  Statue  Report  Operation 

The  Status  Report  Operation  is  defined  as  the  process  by 
which  the  FI -Bus  nodule  with  direct  access  to  the  HSDB  nay  initiate  a 
status  report  to  another  Pi-Bus  nodule.  The  operation  consists  of  the 
set  of  trsnsactions  listed  in  Table  IV.  The  SOURCE  column  identifies 
the  Pi-Bus  nodule  which  originates  the  status  request  (HSDB  nodule). 

TABLE  IV 

STATUS  REPORT  OPERATION 


SEQ 

SOURCE 

DEST 

MESS 

NOTES 

l(TSU) 

* - 

. > 

PARAMETER  WRITE 

a . 

NOTES : 

* 

--> 

a. 

PI -Bus  naster 

Information  destination 
Status  summary 

*US. Government  Printing  Office:  1907  —  540-054/00514 


D-  80 


